[MacPorts] #68766: openssl3 @3.2.0_0+universal may have broken PRNG on High Sierra and older

MacPorts noreply at macports.org
Sun Feb 11 03:40:15 UTC 2024


#68766: openssl3 @3.2.0_0+universal may have broken PRNG on High Sierra and older
------------------------+------------------------
  Reporter:  fhgwright  |      Owner:  neverpanic
      Type:  defect     |     Status:  closed
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:
Resolution:  fixed      |   Keywords:
      Port:  openssl3   |
------------------------+------------------------

Comment (by fhgwright):

 Replying to [comment:74 neverpanic]:
 > If you build it from source, it won't be installed anywhere, so there's
 nothing to remove. Just `rm -rf` the directory that contains the source
 code and it's gone.
 >
 > I'm sure there are also other people on the Cc list of this ticket who
 have compiled software from source before and already know the rough steps
 how to do this. Maybe they want to help out?

 Although working in the source repo is often an easier way to track down
 bugs and come up with fixes, getting the right setup to do a MacPorts-
 style build in that context can take some work (and it's port-specific).
 It's also not the best way to do a "final test", anyway.

 One can test various aspects of a port without actually installing or
 activating it, just by running in the destroot tree.  There may be some
 gotchas, though (see below).

 > A openssl3-devel port does exist according to the Portfile, but maybe
 the conditional way in which it is defined hides it from the PortIndex. In
 that case, `cd "$(port dir openssl3)" && sudo port -v test --
 subport=openssl3-devel` should work.

 The conditional simply says that the -devel subport doesn't exist in the
 cases where it would be redundant.  If it should exist for the current OS
 but doesn't appear in the index, that probably means that one is trying to
 use an index built for a different OS version, which is problematic in
 general and ought to be fixed.  Once it is fixed, then the -devel subport
 should be usable without resorting to the index-bypass kludge.

 Replying to [comment:78 neverpanic]:
 > If you want to test the `apps/openssl`, you can use `util/wrap.pl
 apps/openssl`. That should set up the required environment variables to
 make it use `libssl.3.dylib` from the build tree. Since `openssl list
 -providers` failed when this was broken, it would be helpful if you could
 try `util/wrap.pl apps/openssl list -providers`.

 In general, one can test in the destroot tree after a `port destroot
 <port>`, though sometimes additional setup beyond getting the right path
 may be needed.  In the `openssl3` case, there are two such issues:

 1. It's necessary to use the `libexec` instances, since the normal
 instances are absolute symlinks to the ''installed'' locations, and hence
 useless for this purpose.  I have no idea why they're absolute symlinks
 when relative symlinks would work better.

 2. It's necessary to set `DYLD_LIBRARY_PATH` to point to the
 destroot/libexec `lib` dir, so that it uses the destrooted library rather
 than the installed one.

 The setup in my generic test script is:
 {{{
 if [ "$PROG" == "" ]; then
   PROGCMD=""
 else
   PROGCD="cd \$(port work $PORT)/destroot/$PREFIX"
   PROGCMD="$PROGCD && $PROG"
 fi
 }}}

 With this, in many cases, all the port-specific test needs is:
 {{{
 PROG="bin/<command> <args>"
 }}}

 But for the `openssl3` tests, it's:
 {{{
 PROG="\
    cd libexec/openssl3 \
    && DYLD_LIBRARY_PATH=./lib bin/openssl version \
    && DYLD_LIBRARY_PATH=./lib bin/openssl list -providers \
    && DYLD_LIBRARY_PATH=./lib bin/openssl rand -hex 8 \
    "
 }}}



 > Your test does not cover the universal variant. I was under the
 impression that the problem was not specific to the universal variant. You
 can try the universal variant using `sudo port clean openssl3 && cd
 "$(port dir openssl3)" && sudo port -v test -- +universal
 subport=openssl3`.

 I think you meant "specific to" rather than "not specific to".

 That's not entirely the case.  There are some `-universal` failures, but
 more `+universal` failures.

 My test scripts use `port destroot`, followed by the three commands listed
 above, optionally followed by `port test`.  For variants, I used "none",
 "exactly one", and "all" for the non-universal variants, then combined
 those with both +/-universal.  Based on the evidence that `muniversal`
 doesn't play nicely with the test framework (at least on x86), I didn't
 bother with `port test ... +universal` on x86.  Though there seems to be
 some flakiness in the test framework in general, which may be worse with
 many VMs running simultaneously.

 I didn't bother making a modified Portfile to test 3.1.5 on 10.14+.

 TL;DR: 3.1.5/3.2.1 is no better than 3.1.4/3.2.0.

 The results are:
 {{{
 10.4 ppc:
 3.1.5 -universal passes build/progs/tests
 3.1.5 +universal fails build (broken zlib dependency)
 3.2.1 build fails

 10.5 ppc:
 3.1.5 passes build/progs/tests
 3.2.1 passes build/progs/tests

 (10.4-10.5 ppc64 not available for testing)

 10.4 i386:
 3.1.5 passes build/progs/tests
 3.2.1 build fails

 (10.4 x86_64 not available for testing)

 10.5 x86 (no test with +universal):
 3.1.5 passes build/progs/tests
 3.2.1 i386 passes build/progs/tests
 3.2.1 x86_64 passes build/progs, tests hang

 10.6 x86 (no test with +universal):
 3.1.5 passes build/progs, fails tests
 3.2.1 passes build/progs, fails tests

 10.7-10.8 x86 (no test with +universal):
 3.1.5 passes build/progs, fails tests
 3.2.1 passes build, fails progs

 10.9-10.13 x86 (no test with +universal):
 3.1.5 passes build/progs/tests
 3.2.1 -universal passes build/progs/tests
 3.2.1 +universal passes build, fails progs

 10.14 x86:
 3.2.1 passes build/progs, fails tests

 10.15-12.x x86:
 3.2.1 passes build/progs/tests

 (13.x-14.x x86 not available for testing)

 11.x-12.x arm64:
 3.2.1 passes build/progs/tests

 13.x-14.x arm64:
 3.2.1 passes build/progs, fails tests (tests flaky?)
 }}}

-- 
Ticket URL: <https://trac.macports.org/ticket/68766#comment:84>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list