On 25. 6. 25 01:04, Daniel Sahlberg wrote:
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
I thought I fixed one of those recently? May not have caught them all.
Only the no-signer test no longer works with OpenSSL 3, the others
should, or at least they do for me locally.
(Of course that test still works with LibreSSL, but that's to be ...
expected.)
-- Brane
