-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenSSL 3 deprecation warnings #83
Comments
Actually, these might be worse than just warnings. I'm getting consistent failures in |
I'm on Debian 11, which still uses 1.1.1 |
Our dev&test containers/env is still on OpenSSL 1.1.1f. |
+1 Same issue on arch linux I think the best way to solve this problem is to force users of libp11 to install it as an engine on their system, and configure openssl to use it. Then using the high level EVP API from OpenSSL should be fine. That would reduce the complexity of the project. Not sure if it works but worth a try |
I've just upgraded to Debian 12, which does use OpenSSL 3 :( Turning off the warnings-as-errors gives me a build that fails quite a lot of unit tests, so I agree, there is something bigger that needs looking into here. |
I found the OpenSSL 3 migration guide . It looks like a good chunk of crypto.cc will need updating to move away from the deprecated APIs, but on the bright side at least most of the crypto stuff is already behind a wrapper. |
I think I've figured out why removing the warning about deprecated declarations isn't enough. OpenSSL now doesn't load 'legacy' providers by default. This rather horrible static-initialization hack on the end of crypto.cc gets most of the tests passing on my machine.
I'm still thinking that biting the bullet and re-writing crypto.cc to use the new APIs is the better solution. |
Yeah, I agree. Your trick looks fine for a dirty hack but that's not The Way. |
I think we might have a problem supporting key storage in PKCS#11 and not using the deprecated APIs. The cause is that the 'engine' APIs are used to talk to the HSM via PKCS#11, and the replacement 'provider' APIs would need an alternative to the 'PKCS#11 engine library' that talks the provider API rather than the engine API. There are such things on Github (example) but I can't find one in Debian stable right now. I think the option space is:
Right now I think we should go with the first. I'm not a big fan of differing code paths under |
I agree. If the deprecated APIs still work, there's no urgency to find a new solution, and my memory of the initial PKCS#11 support was that it was quite tedious and took a lot of effort to get working just right. I wouldn't want to go through that again with a library that might disappear or get replaced by something better down the line. Obviously using deprecated APIs isn't great but I think the ecosystem hasn't quite caught up yet. |
I recently updated my OS to 22.04, which uses openssl-3 by default. That's excellent, but we get a bunch of deprecation warnings now, such as:
... and so on. There are also a couple boost errors I'm seeing (with 1.74.0) like this:
The text was updated successfully, but these errors were encountered: