Done: https://github.com/lsh123/xmlsec/issues/339
HTH, Simo. On Tue, 2022-05-17 at 13:33 -0400, Aleksey Sanin wrote: > 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 > > > > [email protected] > > > > http://www.aleksey.com/mailman/listinfo/xmlsec > > > David Bailey <[email protected]> > > > _______________________________________________ > > > xmlsec mailing list > > > [email protected] > > > http://www.aleksey.com/mailman/listinfo/xmlsec > > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
