On 05.05.2018 17:12, Branko Čibej wrote: > On 29.04.2018 11:24, Branko Čibej wrote: >> On 25.04.2018 00:08, Branko Čibej wrote: >>> On 20.04.2018 12:55, Branko Čibej wrote: >>>> Hi! >>>> >>>> Has anyone seen this failure before, on latest macOS with latest tools >>>> and homebrewed APR and OpenSSL: >>>> >>>> There was 1 failure: >>>> 1) test_ssl_missing_client_certificate: >>>> /Users/brane/src/asf/serf/serf-trunk/test/test_ssl.c:1869: expected >>>> <120172> but was <120199> >>>> >>>> >>>> (This is with running "scons check" in an out-of-tree build.) >>>> >>>> The test case expects the status SERF_ERROR_SSL_SETUP_FAILED but >>>> receives SERF_ERROR_ISSUE_IN_TESTSUITE. >>>> >>>> It's strange that the same issue doesn't show up on the OSX buildbot — >>>> but that has a different version of the OS, APR, APU and OpenSSL. >>> This is what I found so far: >>> >>> * the call to 'cctx->handshake()' in _mhRunServerLoop returns APR_EGENERAL >>> o the handshake function called is sslHandshake() in MockHTTP_server.c >>> * the problem is sensitive to timing; if I set MH_VERBOSE to 1, all >>> tests pass ... even if I redirect stderr to a file or to /dev/null. >>> This is true even if I just selectively enable the error logging in >>> sslHandshake(). >>> o if I do that, I get the following log: >>> >>> 2018-04-25T00:05:33.097912+02 [cp:56236 sp:30118] SSL Error 1: >>> Library=20, Function=128, Reason=255 >>> >>> 140735571477376:error:140800FF:SSL routines:ssl3_accept:unknown >>> state:s3_srvr.c:869: >> Well this is interesting ... this test failure does not manifest if I >> build with OpenSSL 1.1.x, only 1.0.2. There's either something wrong >> with my (or rather, Homebrew's) build of OpenSSL 1.0.x, or the "recent" >> 1.1.x compatibility changes somehow broke 1.0.x support. > I updated my OSX build slave from OpenSSL 1.0.2k to 1.0.2o today, and > the same failures started showing up there, too. So it has to be either > a bug in the latest version of OpenSSL 1.0.x, or in the way we use it.
This test failure happens with OpenSSL 1.0.2n and 1.0.2o, but not with 1.0.2m and earlier. Looking at the OpenSSL changelog[1], this is a likely candidate: > Changes between 1.0.2m and 1.0.2n [7 Dec 2017] > > *) Read/write after SSL object in error state If that's the case, then it's most likely due to a bug in Serf. The fact that enabling logging in the tests (i.e., reading the error state) makes the test failure go away seems to point in this direction, too. Unfortunately I'm not familiar enough with those parts of Serf, and it would be really nice if someone else could try to track this down. It looks suspiciously like we're ignoring a return code somewhere ... -- Brane [1] https://www.openssl.org/news/cl102.txt
