[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):

 Replying to [comment:117 kencu]:
 > that would build against {{{${prefix}/lib/libcurl}}}, to build a
 completely new version of {{{Pextlib.dylib}}} that is linked against
 {{{${prefix}/lib/libcurl}}}.
 >
 > Then we might rename and copy that one library into the base
 installation, and use it if it and libcurl exist.

 That could also be a solution, but rather than building all of MacPorts
 "base" it would be better in that case to add a standalone build system to
 the Pextlib component!
 You don't want to build against `${prefix}/lib/libcurl` though, because of
 the potential of openssl version clashing. Though I suppose a
 `port:pextlib` (that's what we're talking about here) could simply be
 built against the same openssl version that libcurl may be using too (if
 installed `+ssl`).

 Replying to [comment:119 catap]:
 > Last week Nginx had an update which includes fixes for 4(!) CVE in
 HTTP/3.

 I know many people consider such things like the holy grail, but just how
 urgent are such hotfixes for the things that libcurl is used for in
 MacPorts? That is, a priori only for vetted downloads with multiple-
 redundant checksums.
 Case in point: most users do this things via a (possibly "ancient")
 libcurl version...

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