[xmlsec] XMLSec with OpenSSL 3.x

Aleksey Sanin aleksey at aleksey.com
Tue May 17 17:33:15 UTC 2022


Thanks for feedback. Do you mind opening an issue for that? I am still
learning the providers stuff so I would appreciate advice on how to
handle it the best way.

Aleksey

On 5/17/22 1:30 PM, Simo Sorce wrote:
> Congrats on this, however I am quite worried about some choices and
> wonder if I should open issues for those.
> 
> I see that now xmlsec unconditioanlly loads the legacy provider in the
> default context.
> 
> This is pretty bad, as it will change the context for the application
> xmlsec is pulled in too, changing what the application now has access
> to.
> 
> We went to great lengths to avoid this in RHEL for example, and I
> pushed code in various upstreams to only load the legacy provider in a
> custom context if absolutely needed.
> 
> In general legacy algorithms are pretty bad and shouldn't be pulled in
> automatically, instead admins can enable the legacy provider via
> configuration if they really need them.
> 
> There are some exceptions where a protocol really needs something
> legacy, that's when I created a special openssl context just for the
> specific legacy invocation.
> 
> xmlsec is pulled in via indirect linking in *a lot* o software even
> when it is not used at all, so this automatic loading of the legacy
> provider really concerns me.
> 
> Can we address this problem before you make a release?
> 
> Simo.
> 
> On Tue, 2022-05-17 at 12:14 -0400, Aleksey Sanin wrote:
>> The real migration to OpenSSL 3.x was much more complex than expected.
>>
>> BIG THANKS to David Bailey (snargit) for creating the PR for the
>> migration:
>>
>> https://github.com/lsh123/xmlsec/pull/334
>>
>> which I forked here to add small polishing:
>>
>> https://github.com/lsh123/xmlsec/pull/336
>>
>> The work is now merged in the master. There are still a few things that
>> needs to be done:
>>
>> 1) Custom engines are deprecated in OpenSSL 3 and are disabled in the
>> build against OpenSSL 3. I will need to think about best ways to migrate
>> that functionality.
>>
>> 2) I want to add automatic builds against OpenSSL 3 since the code is
>> significantly different.
>>
>> However overall, the OpenSSL 3 build is working and ready for testing!
>>
>> Thanks a lot, David!
>>
>> Aleksey
>>
>> On 3/25/22 1:10 PM, Aleksey Sanin wrote:
>>> First, I love patches :) Second, I was planning to look into it sometime
>>> this year. So far, it's indeed a lot of "deprecated" warnings but
>>> I believe everything works. The work is to replace direct structures
>>> access with macros (for old version) or function calls (for newer
>>> versions). Functionality didn't change really so I don't believe it's
>>> super urgent.
>>>
>>> Best.
>>>
>>> Aleksey
>>>
>>> On 3/25/22 10:40 AM, Soós András wrote:
>>>> Hi Aleksey,
>>>>
>>>> The XMLSec library is now compatible with OpenSSL 1.1.x. I would like
>>>> to know when the XMLSec library will be compatible with the OpenSSL
>>>> 3.x version. Yesterday I tried to compile the XMLSec 1.2.30 with
>>>> OpenSSL 3.0.2. It worked fine, but I got a lot of compiler warnings
>>>> about using deprecated functions and structures. Others have already
>>>> inquired about the compatibility, or am I the first one? Refactoring
>>>> the program code is not a little work, I know, because I’m in a same
>>>> project with our own codes. The XMLSec library is a very important
>>>> part of our work, and we plan to keep it for long time to come.
>>>>
>>>> Thank you in advance if you have any encouraging answer.
>>>>
>>>> Best regards
>>>>
>>>> András Soós
>>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>> David Bailey <notifications at github.com>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
> 


More information about the xmlsec mailing list