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

[MacPorts]

#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