Re: How to handle updates to mozilla-rootcerts?

[Havard Eidnes <he%NetBSD.org@localhost>]

> Jonathan Perkin <jperkin%joyent.com@localhost> writes:
> 
>> * On 2018-04-18 at 23:46 BST, Greg Troxel wrote:
>>
>>>   The idea that you install some random package and as a side effect the
>>>   set of configured system trust anchors changes is not ok.  So we
>>>   either need some explicit user choice to let mozilla-rootcerts control
>>>   system trust anchors, or a rule that it can't be a dependency.
>>
>> Could someone explain why this isn't ok?  I'll admit I don't really
>> understand why people have issues with this.  My vague understanding
>> is that some folks don't trust all of the CAs bundled in this package
>> and go through and weed out the ones they don't like, but then what do
>> they do about domains that are signed by that CA?
>
> This is definitely messy.
>
> The entire scheme of public CAs is basically broken; there is a a very
> big list of public CAs, and if a certificate is signed by any of them,
> it is believed.  There have been instances of untrustworthy CAs.  It is
> highly likely that at least one CA currently in the list is currently
> compromised.  Reactions range from not configuring the list to just
> accepting the whole list and choosing not to worry.  In addition,
> there's a parallel universe of CAs for the US government, where they
> more or less trust their own but not the mozilla set, and the USG CAs
> aren't in the mozilla set.

OK, I'm willing to accept this as the background, and I recall
there has been CA compromises in the past and there's likely to
be more in the future.

> 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.)

> 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...

>     - 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?

We only provide a method where the mozilla-rootcerts list can be
installed in system openssl exactly *once*, and no automatic or
manual method is provided to update the list installed in system
openssl once the mozilla-rootcerts package is updated, as might
happen when swithing to use packages from a more recent pkgsrc
release branch.  Why?!?

Thus, if a root CA is eventually removed from the mozilla-rootcerts
package via upstream updates, we have no way to make that update
trickle down to the actual installed list in system (or pkgsrc)
openssl.  This is obviously Bad.  Why is this so difficult to fix?

Regards,

- Håvard