RFC: Proposal: Install a /etc/ssl/cert.pem by default?

[Eitan Adler]

On 4 July 2014 02:11, Ben Laurie <benl at freebsd.org> wrote:
> On 3 July 2014 17:07, Jonathan Anderson <jonathan at freebsd.org> 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