serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: 1.4.0 RC1 release artefacts are available
Date Thu, 25 Oct 2018 14:47:10 GMT
On 25.10.2018 12:16, Branko Čibej wrote:
> On 25.10.2018 11:08, Branko Čibej wrote:
>> On 01.10.2018 15:41, Branko Čibej wrote:
>>> Hi!
>>>
>>> I've just committed the 1.4.0 RC1 release artefacts here:
>>>
>>> https://dist.apache.org/repos/dist/dev/serf
>>>
>>> Please give them a spin. I don't actually plan to officially release the
>>> RC1, so these are not tagged but are just a snapshot from the current
>>> state of the 1.4.x branch. The only planned change for the actual
>>> release are the release date and revision in the CHANGES file.
>> So I *FINALLY* got around to testing with OpenSSL 1.1.x on macOS, and
>> found this:
>>
>> 1) test_ssl_handshake_nosslv2: .../test/test_ssl.c:590: Serf does not disable SSLv2,
but it should!
>> 2) test_ssl_missing_client_certificate: .../test/test_ssl.c:1925: expected <120172>
but was <120171>
>> 3) test_ssl_renegotiate: .../test/test_ssl.c:1881: expected <0> but was <120199>
>>
>>
>> Funny that it worked on Windows ...
>>
>> I really hope the 1st failure is not related to using an apr-util with
>> the crypto module linked to OpenSSL 1.1. Actually that holds for the 2nd
>> failure, too. I should probably try with an apr-util built --without-crypto.
> Nope, that did not help (and I really didn't expect it to, since
> APR-Util doesn't actually load OpenSSL until the crypto module is
> initialized).

I think I've found the problem. OpenSSL 1.1 supports TLSv1.3 and enables
it by default; but the MockHTTPinC server code doesn't know about it and
doesn't disable it. So failure 1. is caused by negotiating TLSv1.3 when
it should be failing due to rejected SSLv2. The fix is rather trivial —
I just added knowledge about TLSv1.3 to the mock server and that appears
to have fixed all three of the test failures.

-- Brane


Mime
View raw message