Re: CVS commit: pkgsrc/security/mozilla-rootcerts

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

Jonathan Perkin <jperkin%joyent.com@localhost> writes:

> * On 2020-03-27 at 16:37 GMT, Greg Troxel wrote:
>
>> Jonathan Perkin <jperkin%joyent.com@localhost> writes:
>> 
>> >> On one of your systems where openssl is provided by pkgsrc, does
>> >> mozilla-rootcerts-openssl work for you?
>> >
>> > It generally just breaks things.  We already ship everything
>> > configured using just mozilla-rootcerts and running the install
>> > script, so installing mozilla-rootcerts-openssl on top is at best a
>> > nop, but at worst just breaks everything.
>> 
>> So you are running something that is not exactly pkgsrc, it seems.
>
> What do you mean?  It is entirely pkgsrc.

I thought you meant a system when you installed mostly via pkgsrc plus
some manual comamnds, vs just installed pkgsrc.  (I realize that the
point really is about handling of etc by packages, and that the
pure/not-pure distinction terminology is not useful.)

>> >   $ pkg_delete mozilla-rootcerts-openssl
>> >   $ curl -I https://whatever/
>> >   curl: (60) SSL certificate problem: unable to get local issuer certificate
>> 
>> That isn't "breaking things".  The administrator explicitly asked to
>> remove the package that configures trust anchors, and so the trust
>> anchor configuration was removed.   To leave them installed would be a
>> bug.
>
> In this case yes, I explicitly uninstalled it.  I'm talking about
> situations where the package might be upgraded, either from source or
> binary, where the package will be removed before a newer one is
> installed.  During that period, which may be a long time if there is
> some issue with the upgrade, the user has now lost the ability to
> reliably download over HTTPS, which may be necessary for them to
> repair the situation.

I see.  Yes, I suppose that could be an issue.  I would say that upgrade
mechanisms should, in an ideal world, have downloaded the replacement
packages before uninstalling.

What happens when openssl is ugpraded?  If the upgrade mechanism is
robust for that, why is it a problem for mozilla-rootcerts-openssl?

>> What did you expect to happen?
>
> I don't expect packages in pkgsrc to be removing files from my
> PKG_SYSCONFDIR that I have placed there.

This package has intended to note that it behaves irregularly.

Perhaps a fix is to have openssl have some config to support finding
multiple trust anchor directories, and to configure (in the openssl
package) someplace like ${PREFIX}/share/openssl/trust-anchors as a place
where every directory in it would be treated as if the contents were in
etc/certs.  Then mozilla-rootcerts-openssl could just install into
there, and avoid writing in etc.  (I realize you still won't like it,
because removing the package removes the config, but it won't interfere
with what you do in etc.)

mozilla-rootcerts-openssl package add a single config line to refer to
one with the bundle, and on uninstall find that line and remove it.


Another fix might be to have pkg_add throw an error whenever installing
any file that already exists.  That would be trouble, as it seems
pkg_delete often leaves files that fail checksum.  So perhaps only in
etc, sort of special for this.

> It's completely against our policies and unlike all other packages.
> Yes, I understand this is a "special" package, but users shouldn't
> have to be aware of special packages, they should just not have to put
> up with breakage.

Are you saying

  So I do not want to use this package.

or

  So I think this package should not exist in pkgsrc and that we should
  remove it?

I'll assume the former.

>> Well that's a bug and we should fix it.  The directory was not created
>> by the package and should not be removed.  I'll have a look.
>> 
>> Did a simple mkdir and re-running then work?
>
> Yes.

I have started a thread to fix this.  I don't understand why certs went
away; the package does not have the dir in its PLIST and there is no
explicit uninstall script.

>> > I don't want mozilla-rootcerts-openssl anywhere near my systems.  Even
>> > in a best case scenario where a user is installing it instead of just
>> > running the install script manually, there is still plenty that can go
>> > wrong (think of an upgrade scenario where something goes awry part way
>> > through and now their fetch and pkg_add commands are broken when
>> > trying to fix things).
>> 
>> That's your call of course.
>
> Sure, and that's what we do, but I need to be explicit here about why
> the -openssl package can be dangerous.  Not very long ago there was a
> proposal on tech-pkg@ that it should be made a mandatory DEPENDS, and

Yes, and I probably spoke strongly against that.  We agree here.

> I'm simply making sure people are aware that the -openssl package is
> entirely superfluous on systems using pkgsrc openssl at best, and
> actively dangerous at worst.

I think this is a point on which reasonable people differ.  For some,
having a package that does things may be preferable to adding an
explicit script invocation to their management practices.  I understand
your point, but I don't want to conclude that everyone who uses
mozilla-rootcerts-openssl is confused.

> Again, I would be much more comfortable if the -openssl package was
> only recommended when using native openssl.  I see zero benefits for
> it to be used on pkgsrc openssl systems, only drawbacks, and it
> clearly causes confusion for people as this thread demonstrates.

I don't really see why native vs pkgsrc is different.  The
mozilla-rootcerts-openssl package does the same thing in each case, only
differing in which etc/openssl/certs it places the certs/links.  The
manual script approach you favor can be used in both cases.  Why is
modifying the system etc/openssl/certs directory better (or worse) than
the one under pkgsrc?

>> On your systems, presumably SmartOS, is there openssl in the base
>> system, or are you using openssl from pkgsrc?   Does the openssl in base
>> have preconfigured trust anchors?
>
> There is a base openssl but it is hidden and only used by some of the
> base programs.  It has no trust anchors.  All of the software that
> regular users execute is provided by pkgsrc, which uses pkgsrc
> openssl, which uses the trust anchors installed by mozilla-rootcerts.

Thanks.  That question was really me wondering about some of the larger
issues of what the appropriate choice is for a base system.  It seems
some configure trust anchors and some do not.