[MacPorts] #70767: python312 @3.12.6 cannot compile against libressl

[MacPorts]

#70767: python312 @3.12.6 cannot compile against libressl
------------------------+----------------------
  Reporter:  SaintBol   |      Owner:  jmroot
      Type:  defect     |     Status:  assigned
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.10.1
Resolution:             |   Keywords:
      Port:  python312  |
------------------------+----------------------

Comment (by neverpanic):

 Replying to [comment:10 artkiver]:
 > Replying to [comment:9 jmroot]:
 > > As far as python312 is concerned, I guess the dependency just needs to
 be `port:openssl` if it doesn't work with libressl.
 >
 > I think, generally speaking, Portfiles would benefit from something such
 as:
 >
 > {{{
 > depends_lib         path:lib/libssl.dylib:openssl \
 > }}}
 >
 > Referencing the dylib facilitates a port to be more TLS library
 agnostic.

 Sure – but in this case the alternate ports that provide
 `lib/libssl.dylib` do not actually work, as Python fails to compile.
 Either (a) libressl needs to commit to providing the same API as openssl
 does, or (b) somebody needs to do the work of making sure Python continues
 to work with libressl upstream by adding appropriate #ifdefs and
 alternative code paths, or (c) somebody needs to do this work downstream
 to patch Python to add this support, or (d) Python needs to depend on
 `openssl`, not on `path:lib/libssl.dylib:openssl`.

 For this case, it seems like it's going to be (d).

 (b) and (c) also wouldn't work correctly, since we build binaries of
 Python that we distribute to users, which would use
 `X509_OBJECT_set1_X509` since the buildbot compiles against OpenSSL. Those
 binaries would not work when installed on a system where
 `lib/libssl.dylib` does not provide this symbol.


 > With regards to ldns, that was from a PR here:
 > https://github.com/macports/macports-ports/pull/17568
 >
 > As suggested by the commit message, the "extra smarts" were inspired by
 modifications made to the rpki-client Portfile, from suggestions provided
 by @neverpanic (at the moment I am not even sure why it is not CCing
 Clemens Lang, did I forget how to use Trac? I swear there used to be a
 means to provide a drop down username select.)

 I suggested these "extra smarts" with the variant precisely so that
 prebuilt binaries compiled against openssl would not be used on systems
 that have libressl installed and vice-versa, since they are not binary
 compatible.


 > It's my personal observation, maybe something changed with how TLS is
 being handled by MacPorts, not just the Portfiles? It's plausible that
 rpki-client also does not function with those similar "smarts" as it did
 when it was originally tested and committed.

 I don't think there's anything that changed in MacPorts. It's just that
 OpenSSL and LibreSSL are no longer compatible (enough), for this to work.


 > However, this kind of stuff would sincerely benefit from more attention
 than I can personally provide at present given my limited resources. I do
 not even have mpbb running locally despite multiple attempts at following
 those instructions, they haven't gelled.
 >
 > I would also posit that rather than defaulting to OpenSSL, defaulting to
 LibreSSL, given that macOS has used that as its reference TLS library for
 approximately a decade at this point, might be a wiser strategy? IIRC that
 may touch over 800 Portfiles though and is more than a one person job, to
 understate it.

 Most upstreams follow OpenSSL, attempting to use LibreSSL would lead to
 problems such as the one in Python reported here. I don't have time to
 make all those ports work with LibreSSL, and neither do I want to
 considering that we'll eventually want to do a post-quantum transition and
 OpenSSL has a working solution for post-quantum cryptography right now
 (using liboqs and oqsprovider) and will integrate one soon. Also,
 OpenSSL's support for smartcards will be vastly improved using
 pkcs11-provider. I don't see any of those improvements happening in
 LibreSSL (although I honestly haven't looked, either).

 Personally, I'd go for OpenSSL and drop LibreSSL support completely.

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