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
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
