[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:127 RJVB]:
 > it could be very helpful for debugging purposes if there were a `curl
 version` command in Pextlib, returning a list of relevant strings
 describing the libcurl currently in use.

 Dog with a bone ... couldn't resist whipping something up after all. `curl
 version` returns a minimum list of relevant strings for the current task
 at hand. It's not supposed to be of use beyond providing some debugging
 information so I haven't bothered fetching more than the information that
 was available from the earliest curl versions onwards.

 BTW, the attentive reader will have noticed that my own "dedicated
 libcurl" copy is still at v8.0.1, not at 8.7.1 as I must have claimed
 somewhere.


 Replying to [comment:129 catap]:
 > Which includes modern OpenSSL.
 >
 > And this is quite deep hole.

 Yes, and as I implied, one best avoided by using a different SSL backend
 like GnuTLS, AT LEAST if we are NOT talking about a Pextlib built as a
 port, so against dependencies from `$prefix`.

 Pextlib also provides the functions for checksum calculation, rmd160 and
 sha256. Those are taken from OpenSSL's libcrypto as installed in the
 system, which could well be from OpenSSL 1.0 (and there's nothing wrong
 with that for calculating just checksums, AFAICT).
 Curl using the OpenSSL backend will link against the libssl from that
 "modern OpenSSL" and libssl is linked against the matching libcrypto. I
 have seen `port` crash when those two libcrypto versions get mixed in the
 same binary. Took me a long time to figure out why both got loaded, too.
 Once I did understand the fix was easy: build a libcurl that uses the
 GnuTLS backend (like the system one on Ubuntu, btw).

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