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

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 2020-03-10 14:27, Greg Troxel wrote:
> Jason Bacon <outpaddling%yahoo.com@localhost> writes:
>
> > Perhaps security/mozilla-rootcerts-openssl should be a run dependency
> > for www/curl?  As ubiquitous as https is now, anyone using curl will
> > probably have to install mozilla-rootcerts-openssl anyway.
> So far, we have taken the position that NetBSD base does not install
> trust anchors by default, and that choosing trust anchors is a decision
> by a system administrator, not someone editing a package.
>
> I would say that if we want to revisit this, we should have a pkgsrc
> default with a variable, and have it not be related to any particular
> package.
>
> Arguably, this is all coming up because curl and wget are now defaulting
> to validating certificates rather than not.  But it's not clear excctly
> how different not validating is compared to adding 100 trust anchors.
> (Yes, I realize it's different - my point is that 100 trust anchors
> leads to quite a lot of exposure.)
A valid point.

If we're going to adhere to that policy at the expense of common tools 
not working out-of-the-box, maybe there's something else we can do for 
curl users like patch in a user-friendly message stating that it's a 
security policy and suggesting mozilla-rootcerts-openssl when this type 
of failure occurs.

Experiencing this sort of failure once and being told it's happening for 
a good reason and how to fix it in 10 seconds might actually be good PR 
for the project.

I've seen a couple of people annoyed by this issue in the past and their 
first inclination was not to use pkgsrc curl or R.  I fixed it for them 
pretty quickly, but it did result in work delays.

    JB