invalid certificate chain during port-fetch

[Mojca Miklavec]

On Sun, 29 Dec 2019 at 13:46, Rainer Müller wrote:
> On 29.12.19 10:50, René J.V. Bertin wrote:
> > On Saturday December 28 2019 21:51:07 Ryan Schmidt wrote:
> >
> >> If I understood the patch correctly, it adds a fallback so that if fetching via the curl library fails, then it tries fetching via the curl command line program. To my knowledge MacPorts has never had code for using the curl command line program, only the curl library.
> >
> > It does, and if it didn't then I guess this snippet must have been proposed during a discussion on a mailing list, or maybe it had already been contributed.
> >
> > Either way, the idea makes sense even if the implementation leaves to be desired, no?
>
> I see no reason for such a fallback. We use libcurl, why should we
> duplicate the code to additionally support curl?
>
> The real problem here is that your operating system is out of date and
> cannot communicate with servers that require modern crypto. Going
> forward, this will affect many more applications and not only MacPorts.

Except in this case it requires 10.12., which is newer than what our
existing infrastructure hardware supports?
Yes, I know that not even 10.11 is supported any longer, so that one
also counts as outdated.
And the port in question is not even in our port tree, but that's
irrelevant to the discussion.

> 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:
- manually downloading and copying the files (out of question, too
much work, cannot be automated)
- constantly fighting with broken updates & not being able to test anything
- shipping our own bundled copy of libcurl (dismissed many times as
not feasible)
- introducing a cyclic dependency & chicken-and-egg problem of using
curl or wget as we ship it (not possible)
- installing a second copy of macports just for the sake of being able
to build libcurl, manually building the full compiler toolchain just
for that simple program, manually compiling macports and getting the
change overridden each time MacPorts  is outdated (the only acceptable
solution that's annoying at least)
...
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. It could be a non-default configuration
option that only interested users on older systems would turn on, or
that would only be turned on by default on older systems ... to make
their user experience slightly better.

(Keep in mind that while this is definitely not our main focus, we are
probably the best package manager as far as support for older OSes is
concerned.)

Mojca