[MacPorts] #51516: MacPorts should use a bundled copy of a newer libcurl and SSL library rather than the OS X version

[MacPorts]

#51516: MacPorts should use a bundled copy of a newer libcurl and SSL library
rather than the OS X version
--------------------------+--------------------------------
  Reporter:  ryandesign   |      Owner:  macports-tickets@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:  MacPorts Future
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by RJVB):

 seeing the size of that Portfile I am beginning to think that the most
 efficient implementation would be as a subport of `port:curl`, even if
 that means keeping a few patches for (say) an LTS version in a
 subdirectory. The curl port maintainer may have a different opinion of
 course.

 - why curl 8.2.0 and not 8.7.1 for instance?
 - I'm confused about what exactly is meant with "for bootstrapping" here.
 Is this port meant to be temporary, replaced by a less-minimal (lib)curl?
 Apparently so, because I don't see it being configured for installing in a
 dedicated location.
 - That in turn means that Pextlib shouldn't be linking to it directly -
 are we back to considering an approach using `dlopen`/`dlsym`?
 - My memo about avoiding the SSL backend has not made a lot of impact it
 seems. Again, that argument is moot if we can build a Pextlib copy against
 the same OpenSSL version as the one used by libcurl, or let Pextlib use an
 alternative to OpenSSL's libcrypto. If not, and if the bootstrap curl
 won't be built against the same major OpenSSL version as the system
 provides (seems counterproductive to me) then that bootstrap curl should
 use a different backend.

 Is there any reason NOT to use the GnuTLS backend for the purpose at hand?
 It seems to be good enough to be used as the default in Ubuntu...

 If SSL really is to be preferred, what other options are there to avoid
 different versions clashing, that don't involve a complete overhaul of the
 Pextlib parts that depend on libcrypto?
 What's the status of LibreSSL for instance? Now that there is
 infrastructure for using different, co-installed OpenSSL versions, could
 LibreSSL be somehow included or at least get a similar treatment
 (installation under $prefix/libexec) ''and would that be of any help
 here?'' IOW, will curl's SSL backend work with LibreSSL and can LibreSSL
 and OpenSSL be used in a single running application without biting each
 other?

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