Re: How to handle updates to mozilla-rootcerts?

[Greg Troxel <gdt%lexort.com@localhost>]

Havard Eidnes <he%NetBSD.org@localhost> writes:

>> Jonathan Perkin <jperkin%joyent.com@localhost> writes:
>> Browsers have a preconfigured set of CAs, and this is usually close to
>> the mozilla set.  Operating systems are far less uniform.
>>
>> So far, NetBSD has chosen not to install trust anchors in the system
>> openssl.  You can view this as a cop-out for not dealing, or taking the
>> high road and separating policy from mechanism, but that's how it is
>> today.  Other systems seem to have varying approaches, and I'm not clear
>> on exactly which ones take which paths.  To avoid getting into
>> validating CAs, it seems an OS should choose between 1) none and 2) the
>> mozilla list.
>
> Right.  This is what motivates the existence of the mozilla-
> rootcerts package, which is also fine.
>
>> As for weeding out CAs, I don't really know how people typically choose.
>> The issue is not so much domains signed by untrusted CAs, as that having
>> an untrusted CA in the trust anchor set means that if a cert for some
>> other domain is presented, it will be believed.
>
> I suspect that most folks are not aware that they have the option to
> pick and choose from the mozilla-rootcerts list, they merely know of
> "none" and "the mozilla list".  I suspect that the group of people
> who want to be picky wrt. which CAs they trust are in the ignorable
> minority with respect to how pkgsrc should deal with this, i.e. they
> can probably be left to craft their own setups -- we should however
> cater for the "typical".  (Sure, if this can be made sufficiently
> flexible to also optionally cater to special needs, that's fine
> too.)

But, NetBSD the base system has made the choice not to do that.  This is
not fundamentally different from "sshd should be listening by default
and allow root logins without a password, because its convenient" (but a
huge difference in degree, I realize).

>> With pkgsrc, we have multiple questions:
>>
>>   - do we install trust anchors in the system openssl?
>>     - if the user explicitly requests this?
>
> I think this is the choice which is currently taken, i.e. the user
> needs to run the command in MESSAGE to do this.
>
> Now, as has been mentioned, relying on the system administrator to
> act on the contents of MESSAGE is probably misguided, and makes for
> a poor operator experience, but so far it seems the general pkgsrc
> choice is that anything which modifies system behaviour or
> configuration should require manual additional action.  So I'm not
> challenging that choice for now, merely grumbling at it...

Sure, and I'm a MESSAGE hater (I'd vote for just removing them all and
deleting the feature :-).  But we have mozilla-rootcerts-openssl, which
is supposed to do as you describe.

>>     - as a side effect of building or installing something else?
>>
>>   - do we install trust anchors in pkgsrc openssl?
>>     - (explicitly)?
>>     - (side effect)?
>
> I beleive I posed different question than any in your list, which is
> this:
>
>   Given that a user has already chosen to install the mozilla-
>   rootcerts package, and has run the script to make those certs
>   available to system openssl, why is it so that it appears to not
>   be possible to refresh the system openssl configuration after a
>   corresponding update of the mozilla-rootcerts package?

That's a fair point, but if we separate mozilla-rootcerts as "put the
certs where they could be used" and "mozilla-rootcerts-openssl" as
"cause them to be used for openssl", then we can make the INSTALL script
do the right thing.  That's just code, and I don't think controversial.

The thing that's objectionable is having certificates added as trust
anchors, contrary to the base system decisions, without sysadmin action.