Opened 4 weeks ago

Last modified 2 weeks ago

#63421 assigned defect

openssl @ 1.1.1l: tests fail when building on 10.11

Reported by: msquire (Mike Squire) Owned by: larryv (Lawrence Velázquez)
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: elcapitan Cc: neverpanic (Clemens Lang)
Port: openssl

Description

'port test' fails on 10.11, specifically the '05-rand_test.t' test. The port has a patch which includes the relevant CommonCrypto headers in include/crypto/rand.h if the OS version is >= 10.10 with this conditition:

#  if (defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101000)

This is enough to make it build without error, but unfortunately the test fails. I managed to fix it by changing the 101000 to 101200 so it doesn't use the CommonCrypto stuff with El Capitan but I don't know if this problem exists with later versions too. It is possible that in fact the test is broken on older versions, but I am afraid I don't know enough about it to be any further help.

Change History (5)

comment:1 Changed 3 weeks ago by fhgwright (Fred Wright)

It looks like the test failures are unrelated to the patch mentioned above, and not entirely reproducible. I've run the tests 3 times on 10.4-1.13 Intel, as well as once on 10.4-10.5 ppc and on 10.14-10.15 Intel, with the following results:

10.4-10.5 ppc:  Passed once
10.4-10.5 i386:  Passed three times
10.6 i386:  Failed three times
10.6-10.8 x86_64:  Failed three times
10.9-10.11:  Passed three times
10.12 x86_64:  Failed once, passed twice
10.13 x86_64:  Passed three times
10.14-10.15 x86_64:  Passed once

Note the three passes on 10.11 (without any change beyond my own 10.4 fix), as well as the inconsistent behavior on 10.12.

Based on a preliminary look at the logs, it looks like this is related to the test framework rather than the code being tested. I haven't yet tried the previous version to see if this is a new problem.

comment:2 Changed 3 weeks ago by kencu (Ken)

Your thoroughness is inspiring. What do you see as our safest path forward?

comment:3 Changed 3 weeks ago by msquire (Mike Squire)

Indeed, kudos for thorough testing!

I did a little bit more investigation myself... It is interesting that it passed for you on 10.11 - I have just tried 10 clean builds and the test always fails for me. If it is relevant, this is a Mid-2009 MacBook Pro, and here is some version information:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G22010
$ xcodebuild -version
Xcode 8.2.1
Build version 8C1002

Running the test in isolation produces these errors:

# ERROR: (int) 'status == 0' failed @ test/drbgtest.c:697
# [11] compared to [0]
# ERROR: (bool) 'test_drbg_reseed_after_fork(master, public, private) == true' failed @ test/drbgtest.c:799
# false

And looking at the offending test it seems the failure is because the child process it forks off is segfaulting.

I hope this helps.

comment:4 Changed 2 weeks ago by kencu (Ken)

after much waiting, OpenSSL 3.0 has been finally released:

https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/

So I suspect that is where most of our openssl efforts will soon be expended.

comment:5 Changed 2 weeks ago by msquire (Mike Squire)

Nice. I downloaded the 3.0.0 source code and tried to build it to see what would happen. First thing I needed to do was pass the "no-asm" flag to the Configure script because the build bombed out with a whole load of errors when it tried to compile the assembler modules. This made it build without error, but the same test failed as before with 1.1.1l. And apparently for the same reason (segfaulting child processes in the test).

Turns out the changes made by the patch to 1.1.1l are in the upstream 3.0.0 release so to make it build successfully and pass all the tests I needed to do:

./Configure no-asm -DOPENSSL_NO_APPLE_CRYPTO_RANDOM
make
make test
Note: See TracTickets for help on using tickets.