[xmlsec] XMLSec with OpenSSL 3.x

[Simo Sorce]

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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc