[MacPorts] #68766: openssl3 @3.2.0_0+universal may have broken PRNG on High Sierra and older
MacPorts
noreply at macports.org
Fri Apr 19 23:09:27 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 RJVB):
Replying to [comment:85 neverpanic]:
> So where are we with this?
I'm wondering too, in particular under which conditions OSSL 3.2.1 (and/or
now 3.3.0) does NOT fail to build or work on "older" OS versions. The
ticket has grown too long and I think a recap would be useful.
- does it actually work in non-universal builds if a recent enough
compiler is used, and if so, on what OS versions?
- I see no mention of any testing with GCC (say 12 or 13); can using that
compiler give a way out?
IMHO it would not be acceptable to remove the fallback for "legacy"
systems given the 10.14 cut-off; that would leave a number of still
perfectly usable generations of Apple hardware without functional OSSl3 at
all. It would be far better to add a section to the OSSL3 Portfile that
doesn't require significant maintenance, for instance one that turns the
port into a dummy depending on something like `port:openssl31` if the
conditions are not united to guarantee a functional OSSL 3.2+ build.
OpenSSL only depends on port:zlib (really?!) which itself evolves hardly,
so the amount of maintenance for port:openssl31 should be negligible once
upstream no longer provides updates, esp. if the port is kept specific to
the Darwin versions it is intended for (and labels itself
obsolete/replaced_by openssl3 on current versions).
Having an "old" but working OSSL install is always better than not having
one, or having an even older one. Users of old hardware that can only run
legacy OS versions are probably aware that they're exposing themselves to
risks but it's not the responsibility of any port maintainer nor MacPorts
as an institution to protect them from themselves.
Could it be that the failure in universal builds has something to do with
e.g. a binary seed file containing data that is interpreted differently by
32 and 64 bit builds?
---
PS: adding a `+tests` variant speeds up the build significantly.
--
Ticket URL: <https://trac.macports.org/ticket/68766#comment:87>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list