[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