Den fre 20 juni 2025 kl 06:12 skrev Branko Čibej <br...@apache.org>:
> 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 > Thanks Graham for the PR. I've spent some time trying to understand the issue and verify the changes. I've committed the patch in three separate parts, the Python3 changes previously, the new flag and the sha256-signed certificates tonight. This resolves one failing test on Fedora42. I'm getting errors in test_ssl_ocsp_verify_response* (five tests in total) on F42, both before and after the patch, it seems this was already a problem in 2022: https://lists.apache.org/thread/371khw4xrz8c147vspwj4fhf50b8zy2y Cheers, Daniel
