[MacPorts] #51516: MacPorts should use a bundled copy of a newer libcurl and SSL library rather than the OS X version
MacPorts
noreply at macports.org
Sun Jun 2 14:48:17 UTC 2024
#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
More information about the macports-tickets
mailing list