Re: fixing libfetch as a first-class object

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: Thu, 28 Dec 2023 15:16:34 -0500
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Are there any concurrences, or arguments that this doesn't fix the
> tls-non-validation bug in a reasonable way?

(The following is not an objection, because the most important thing
here is to get https validation enabled in NetBSD 10.0 for https-only
scenarios that don't redirect to http.)

I maintain that pkg_add and pkgin should both guarantee the following
simple security contract out of the box:

   If you ask for https://... then every byte over the network is
   authenticated from the peer before any other software acts on it.

The change you're proposing can also break the functionality of
systems that _don't_ ask for https, but ask for http and get
redirected to https -- that is, breakage depends not just on local
configuration but also on the behaviour of remote servers.

So this change is riskier on both security and compatibility grounds
than the patch I proposed at
<https://mail-index.netbsd.org/tech-pkg/2023/12/09/msg028594.html>,
which -- to me, at least -- makes this change less attractive as a
security fix fit for pullup to a branch.

If we use an environment variable, I suggest SSL_NO_VERIFY_PEER, which
FreeBSD libfetch already uses, and which I already drafted at
<https://mail-index.netbsd.org/tech-pkg/2023/12/22/msg028656.html>; no
need to invent a new paint for this bike shed.


That said: I just spent nearly all my spare time of the last month
designing, implementing, testing, and arguing for a careful change for
both pkgsrc-2023Q4 and netbsd-10 to provide this security contract
with a bypass switch, with minimal risk of breakage in library callers
and in existing pkg_add and pkgin configurations, and I've lost
interest in working any more on this for now -- so if you want a
different patch from the ones I already posted, someone else will have
to draft and test it.