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

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

Jason Bacon <outpaddling%yahoo.com@localhost> writes:

> On 2020-03-10 17:55, Greg Troxel wrote:
>
>> If you want to bring up on tech-pkg that pkgsrc should by default force
>> the mozilla root certs to be installed whenever *any package* that uses
>> openssl is installed, we can have that discussion.  I think it's got to
>> be either "this is the pkgsrc way" or "this is not the pkgsrc way" for
>> automatic (with a user tunable since obviously if we change not
>> everybody is ok with that), and that "I installed R and now my trust
>> anchors have changed" is madness (for any value of R :-).
>
> I'm not trying to be critical of the security policy and I'm not
> pushing for a dependency.
>
> I'm just looking at it from the perspective of potential new
> developers and suggesting a solution that will prevent them from being
> scared off.
>
> The fact is pkgsrc curl out-of-the-box will fail to download many
> https URLs where most other curl binaries will succeed.  People

Do you really mean that, or do you mean that curl as installed on other
operating systems will find trust anchors that are installed by default
on those systems?

> unfamiliar with the pkgsrc security policy will likely see this as a
> bug and develop a poor first-impression of pkgsrc.  All we'd have to

Really the pkgsrc security policy here is to respect the OS security
policy.

> do in this case is see where curl is printing the error message and
> add another print suggesting that the user might need
> mozilla-rootcerts-openssl.
>
> I'm fine with with the security policy, but I think if new users are
> going to encounter apparent problems that they don't see with other
> package managers, it would be good for the project to quickly provide
> the reasons and solutions wherever possible.  We can easily turn a
> negative experience into a positive in this case.

So on your Linux systems, can you explain the trust anchor situation?
Are they installed, and does native-packaging curl use them?

Do you think this could be pkgsrc  enabling validation, and other
systems not?

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.

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.