invalid certificate chain during port-fetch

[Ryan Schmidt]

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.