On 4 July 2014 02:11, Ben Laurie <[email protected]> wrote: > On 3 July 2014 17:07, Jonathan Anderson <[email protected]> wrote: >> Eitan Adler wrote: >>> >>> Perhaps we should remove HTTPS support from libfetch and require the >>> user to install wget or curl if they want to use SSL? Having a >>> *default* certificate bundle (that could be removed / edited, of >>> course) is not necessarily even making a trust claim about a >>> particular cert. [0] IMHO the position where the majority of SSL on >>> the internet is broken by default is not tenable. >>> >>> We support HTTP. We don't support HTTPS. The browsers spend a lot of >>> time on this problem. We don't. I am not asserting that the Mozilla >>> set is perfect. I am asserting that we should have *functional* SSL >>> in the base system, and that using the Mozilla set is a good way to >>> obtain that with a good enough policy. >> >> >> I think it's useful to provide the *mechanism* (libfetch does validation of >> whatever certs you put in /usr/local/etc/ssl), I'm just saying that we >> should be very conservative about *policy*: we can vouch for exactly one >> certificate, and that's the one we control. Vendors who base their products >> on FreeBSD might choose to pre-populate /etc/ssl with ca-freebsd.pem and >> ca-vendor.pem, while people who install FreeBSD boxes can choose to install >> a CA bundle package to /usr/local/etc/ssl. >> >> I do see a couple of potential solutions to the "I can't fetch anything on >> my clean install" problem. First, we can make sure that CA bundles are in >> the set of packages we put on the install media, so the person installing >> the OS can choose to adopt the "accept whatever CAs Mozilla likes" policy >> (or the "accept CAs that Dr Paranoid likes" policy). Second, we could let >> interactive 'fetch' warn users about unrecognized CAs (different from >> validation failures) and prompt as to whether or not they want to continue >> with the fetching. That behaviour would be no worse than manually specifying >> --no-verify-peer, which is the logical next step when you see a missing CA >> error today. > > +1. I agree that not making policy decisions on behalf of the user is > the right thing to do, but likewise, leaving them entirely to their > own devices will just lead to further fail, so a port or ports that > will allow users to adopt someone else's policy seems like a necessary > part of the equation. Lets stop conflating "default" with "policy decision". -- Eitan Adler _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"