invalid certificate chain during port-fetch
Mark Anderson
mark at macports.org
Sun Jan 5 01:56:35 UTC 2020
Yeah, not unlike how we bundle Tcl/tk now. Once upon a time, we used the
system version of that too. With Apple looking to ditch supporting a
"system version" of things like python, I imagine we might be better off
with libcurl/openssl. The only problem there is ssl has a lot of
security patches so we might have to make a lot of point releases.
—Mark
On Fri, Jan 3, 2020 at 2:22 AM Ryan Schmidt <ryandesign at macports.org> wrote:
>
>
> On Dec 29, 2019, at 10:58, Mojca Miklavec wrote:
>
> > On Sun, 29 Dec 2019 at 13:46, Rainer Müller wrote:
> >
> >> See also:
> >> https://trac.macports.org/ticket/51516
> >
> > Thinking of it ... the reported/suggested patch doesn't sound as bad
> after all.
> >
> > Considering the potential alternatives of:
>
> [snip]
>
> > - shipping our own bundled copy of libcurl (dismissed many times as
> > not feasible)
>
> I still believe bundling libcurl and libressl or openssl with MacPorts is
> the correct solution, as I have previously argued in #51516. There is also
> a link in that ticket to an implementation, so it is definitely feasible. I
> have not had the energy to renew the argument in that ticket after the
> latest objection, and there are only so many ways that I can express the
> views that I've already expressed there.
>
>
> > then trying to repeat the download with either ${prefix}/bin/curl or
> > ${prefix}/bin/wget or whatever "default curl" points to (which would
> > always resolve to /usr/bin/curl if port curl is missing) doesn't sound
> > like such a bad idea to me.
>
> [snip]
>
> It is a bad idea in as much as it means we are writing all of our curl
> code twice: once for libcurl and a second time for the curl program. This
> is a duplication of effort and presents a great opportunity for us to mess
> up such that a MacPorts feature works when using libcurl but not when using
> curl or vice versa.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200104/765dae74/attachment.html>
More information about the macports-dev
mailing list