Re: Does mozilla-rootcerts-openssl need to be unconditionally NOT_FOR_UNPRIVILEGED?

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 03/11, Greg Troxel wrote:
> I think it's entirely fair to revisit the policy.   Now, a lot of
> programs that use TLS are 1) relying on system trust anchors and 2)
> defaulting to requiring validation.  That leaves us at one of
> 
> 1) configure some set of trust anchors in the OS
> 
> 2) change the programs to default to not validate
> 
> 3) ask users to deal individually
> 
> and we are at 3 now.  I don't think we should do 2.
 
I definitely don't think #2 is a good idea.

#3 is annoying because as a user, if I install curl with "pkgin install
curl", I expect it to just work.

What about adding a TRUST_ANCHORS_TYPE variable to mk.conf that accepts
values like "native", "mozilla", etc.?

Or maybe instead the variable should be TRUST_ANCHORS, and it accepts
a list of encoded values such as "file:/etc/ssl/certs/ca-bundle.crt",
"dir:/etc/ssl/certs", "package:mozilla-rootcerts", etc.?

And there should be a pkgsrc bootstrap switch for it too that
defaults to "native" (for the TRUST_ANCHORS_TYPE idea) or
"file:<path-to-native-trust-anchors-bundle>" (for the TRUST_ANCHORS
idea).

Then I'm not sure of the best approach to find the native trust anchors.
You could make it need to be specified at bootstrap time, with the
option to explicitly set it to none.  That seems not too helpful,
though, but maybe it's the best that can be done.  It would be nice if
the bootstrap could know how to find the native trust anchors on all the
supported platforms, but maybe that's too difficult, I don't know.

If this doesn't fall on the pkgsrc bootstrap, perhaps it could fall on
a pkgsrc package to provide it.  You could have a trust-anchors-native
package that knows where the native trust anchors are and creates
symlinks to them under pkgsrc PREFIX, or something like that.  Or maybe
it should fall on the pkgsrc mk infrastructure kind of like how native
implementations of pkgsrc packages can be found and provided.

And then macOS presents a difficulty in that I think it doesn't store
its system trust anchors in a regular PEM (or similar) file.  Instead,
it stores them in keychains (e.g., the system keychain) and uses its
own Security framework.  I assume the native macOS curl retrieves trust
anchors via this mechanism.  I think there is a way to export a keychain
to PEM format using the macOS security(1) program, but you'd have to do
that after any change to any keychain you wanted to keep in sync, and
I'm not even sure that just because a certificate is in a keychain, it
is trusted; I think macOS stores information about what level and kind
of trust a certificate has been assigned somewhere else.  So, exporting
to PEM doesn't seem like a solution that could even really work.

> The underlying elephant in the room is the entire scheme of having 100
> trust anchors and believing that they all behave correctly and that
> every subordinate CA they certify behaves correctly.   We have seen
> failures of this, and there are increasingly mechanisms to mitigate the
> situation (certificate transparency, CAA
> https://tools.ietf.org/html/rfc6844
> https://tools.ietf.org/html/rfc6962
> ).  However, it's largely how things are now.

Right.  When a web browser like Firefox bundles its own trust anchors,
by using it, you're trusting all of the trust anchors that the Firefox
developers have decided to trust.

Lewis