On 19. 6. 25 23:06, Graham Leggett wrote:
On 18 Jun 2025, at 17:18, Branko Čibej <br...@apache.org> wrote:
While adding OpenSSL3 support to serf, I stumbled on a test failure
caused by MD5 having been removed from OpenSSL.
This led to adding a dedicated error message for it, then updating
md5 to sha256 when generating a test CRL, then updating the
certificate creation script to work with python3, then updating the
test certs.
Serf already supports OpenSSL3*;
Serf can build against OpenSSL3, but exclusively uses PKCS12_parse
functionality from OpenSSL v0.9.3 from 25 years ago.
https://github.com/apache/serf/blob/8abcc9106aa9ee2f2618584c8c206c830359e6f1/buckets/ssl_buckets.c#L1647
When subversion dropped neon support, what was also dropped was all
TLS interfaces that supported smartcards, etc, and all error handling.
In OpenSSL v3, the OSSL_STORE_open_ex() function was introduced:
https://docs.openssl.org/3.3/man3/OSSL_STORE_open/#copyright
This interface takes certificate stores described by URIs, rather than
certificate stores reachable by a filesystem path. Examples of URIs
are file: (existing functionality), pkcs11: (smartcards), tpm2:
(TPMs), cng: (Windows native certificate store), etc.
This interface since OpenSSL3 also supports callbacks so you can use
passphrases - that is what made it useful.
When I say "add OpenSSL3 support", I mean "use OpenSSL3
functionality", not "compile against".
I use it to build trunk and I don't see this issue when I run the
tests. Where is this coming from?
Modern Redhat and derivatives have for better or worse physically
removed old algorithms like MD5 and SHA1. They've also physically
removed support for python2.
This creates some awesome pain.
Export a PKCS12 file from keychain on a 2025 Mac and copy it to a
Redhat derived VM and it uses an obsolete RC2-40-CBC cipher. But there
is no way to know that, because the error that the signature isn't
recognised is thrown away and replaced with "An error has occurred".
https://msicc.net/exporting-apple-distribution-certificates-for-cicd-the-right-way/#:~:text=for%20security%20reasons.-,When%20Did%20This%20Break?,cert%20with%20a%20supported%20cipher.
The test suite in serf runs, and fails, because in 2021 a CRL was
generated containing an MD5 signature, and because MD5 has been
removed from OpenSSL on Redhat, and because all errors are thrown away
the reason logged by the test is "An error has occurred".
Redhat users need to be able to use subversion without needing gdb
skills, and that's why I'm here. This doesn't work for Windows users
either, probably for the same reason.
Subversion has some support for verifying server certificates from the
cert store, but AFAIK not for client certificates. So this is another
good thing.
Thanks for the explanation. I wasn't aware that RedHat-derived systems
had a patched OpenSSL distro. This all makes perfect sense.
-- Brane
