tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On 3/11/20 3:10 PM, J. Lewis Muir wrote:
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

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


Sorry for the incredibly long silence on this.  I've been overrun by rioting worms from too many opened cans and I'm just beginning to restore order.

Below is output showing that the issue still exists on CentOS.

I like the idea of a trust anchors variable in mk.conf.  Whenever there's good reason to have different views, let the end-user decide.  I would add a question to auto-pkgsrc-setup so the issue is dealt with during setup as the user sees fit.



Linux centosdev.uits  bacon ~ 1002: (pkgsrc): curl -O
  % Total    % Received % Xferd  Average Speed   Time    Time Time  Current
                                 Dload  Upload   Total   Spent Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here:

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Linux centosdev.uits  bacon ~ 1003: (pkgsrc): which curl


===> Installing binary package of mozilla-rootcerts-openssl-2.6
Linux centosdev.uits  bacon ~/Pkgsrc/pkgsrc/security/mozilla-rootcerts-openssl 1006: (pkgsrc): cd Linux centosdev.uits  bacon ~ 1007: (pkgsrc): curl -O
  % Total    % Received % Xferd  Average Speed   Time    Time Time  Current
                                 Dload  Upload   Total   Spent Left  Speed
100  465M  100  465M    0     0  8211k      0  0:00:58  0:00:58 --:--:-- 7434k
Linux centosdev.uits  bacon ~ 1008: (pkgsrc):

Home | Main Index | Thread Index | Old Index