Support openssl 3.0.0 #633
Conversation
|
Test failures seem to be unrelated to my changes |
|
Found few more tests that fail due to DES key use.. |
abbra
force-pushed
the
support-openssl-3.0.0
branch
from
496fe2c to
ca037b3
Compare
|
Hmm, I get: Complete build log with all versions of packages used and steps taken to reproduce. |
|
Please rebase for retesting |
abbra
force-pushed
the
support-openssl-3.0.0
branch
from
ca037b3 to
bdd1cd7
Compare
|
When trying this patch on the top of the current |
abbra
force-pushed
the
support-openssl-3.0.0
branch
from
bdd1cd7 to
a8f611d
Compare
|
@abbra, can you add a CI target for "{linux,macos,windows}-openssl3" or similar so we can get test coverage with OpenSSL 3 and 1.1.x at the same time? |
abbra
force-pushed
the
support-openssl-3.0.0
branch
from
46f0ca4 to
b69cd17
Compare
|
I have to push few more updates, sorry. There is an issue with rebasing my older patches around tests, so some of them aren't correct. |
Signed-off-by: Alexander Bokovoy <[email protected]>
OpenSSL 3.0 moves DES into a legacy provider which has to be loaded explicitly. By default, it will not be loaded and DES methods in tests will fail. Nest test blocks under successful initialization. Signed-off-by: Alexander Bokovoy <[email protected]>
Signed-off-by: Alexander Bokovoy <[email protected]>
OpenSSL 3.0 on systems with systemd-wide crypto policy (Fedora, RHEL, CentOS 9 Stream) might block certain key sizes which causes the tests to fail. Skip these tests because we are not going to get the results anyway. There is no way with CPPUNIT to produce a warning only, so we have to skip the whole test result. Signed-off-by: Alexander Bokovoy <[email protected]>
Signed-off-by: Alexander Bokovoy <[email protected]>
abbra
force-pushed
the
support-openssl-3.0.0
branch
from
b69cd17 to
8d8b727
Compare
|
Also, Fedora does not have engine API enabled anymore, so I cannot build locally anymore, need to pull a patch that disables engine's support but that one will break on other openssl versions. |
|
CI now updated, please merge |
|
Almost there, now only few tests are failing: THANK YOU! |
|
Setting as draft until tests passes. |
|
Yeah, sorry, had no time to look at that... |
|
I just created #783 which will enable legacy provider so it will still keep testing the legacy things. I also added a new job for ubuntu 24.04 but think it makes sense to also run it with Botan. In terms of this PR, I think the main issue is that it can actually hide problems in the implementation (e.g. ignore real failures in legacy algs implementation). After my change it's really just about dealing with non upstream RHEL changes which I'm not sure need to be address here. I think that anyone who wants to run tests there should just compile their own version of OpenSSL which is pretty easy. But if there was a need to really make it work nicely there, I think better solution would be to identify it during the configuration (m4 macro checking) and then just compile out parts that are not supported. |
|
Maybe if it's too tricky to identify that the algs are disabled without the policy, it would be ok to introduce some special config options for that. I might actually look into it as I have a similar issue in PHP, where I maintain openssl extension, and we have a similar request there. |
This is absolutely unacceptable idea for the Linux distributions. Of course, we have pre-existing build of OpenSSL and yes, we would like to have tests run to gain at least some hope for the package being functional. |
Well distributions can patch the tests as well. I think this is what is being done for PHP packages - some tests are modified only in the distribution version to work there. In our case we also use some EC group functionality that is patched out there. I'm not saying that's ideal but it is something that can be done instead. Anyway it probably makes more sense to have those changes upstream and I will be actually looking into the better solution for PHP so might try to apply it then here as well which would be probably ideal. I think the current solution of ignoring failures is not ideal and it might be better to look into a bit more robust way. |
|
Just an update that I was looking into the similar thing in PHP and best solution for that are build and then compile time checks. But honestly I'm not sure if it makes much sense to do that before the things get updated to the new API (using EVP and parameters). I started looking into what it would take here as we were doing a similar thing in the PHP openssl extension. It's kind of similar here although it will require a bit more tweaking because there is that extra abstraction separating keys and the actual operations. It's not small amount of work but it's doable. Unfortunately and I currently have to prioritise open source work that I have some funding for. So this is kind of my free time looking which is very limited time wise so it will probably take ages to get anywhere... But will see maybe things will change and I will find some time or there will be someone else to implement this. In any case, it's something that should be done otherwise it will soon stop working with OpenSSL completely at some point. |
|
Ok so I just decided to give it a try and started with DH migration: bukka#1 . It's the first shot and needs some minor fixes but think it's a good start. It still requires much more work to migrate everything and get rid of all deprecations but with some persistence, it should be doable. |
4 participants
This is a first step to make SoftHSM compiled and tests running with OpenSSL 3.0.0 under CentOS 9 Stream (similar to Fedora 34). We cannot use DES anymore there without loading a legacy provider but even if it is loaded, system-wide crypto policies on Fedora/CentOS Stream/RHEL would forbid its use. Same with RSA 1024 or lower key sizes.
The test changes simply make it so that the tests are only run if we are able to initialize encoders or generate keys to work on. Sadly, CPPUNIT cannot produce warnings-only output, they have to be either failures or success, so I have to skip tests that cannot be run.