Re: new certificate stuff

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Mon, 28 Aug 2023 08:42:58 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
> 
> > How is using /etc/openssl/certs/.certctl as the token different from
> > using /etc/openssl/certs.conf as the token?
> 
> Because normal updates merge etc in various ways, and if certs.conf
> comes along with that (because it is in etc.tgz) then that is automatic
> and not an admin action.
> 
> > How does this satisfy the two criteria I set down in the previous
> > message?  Repeating here:
> >
> > (a) new installations get /etc/openssl/certs populated out of the box,
> 
> that dir is empty and certctl can write to it and set the sentinel.
> There is no problem populating an empty dir because that's not removing
> admin config.

OK, thanks, that's a good idea and I implemented it.  (I also fixed an
embarrassing mistake where I had added certs.conf to base rather than
to etc!)

The critical part I had missed is that certctl can claim _either_ a
directory it has already claimed, _or_ an empty directory, so it works
for new installations and to update pristine but old installations.

The way it works in HEAD is now:

1. New installations get /etc/openssl/certs populated out of the box.

2. On updates to existing installations that have _empty_
   /etc/openssl/certs, postinstall will take charge of it and populate
   it like a new installation.

3. On updates to existing installations (whether from 9.x to 10.0, or
   from 10.0 to 10.1) that have _populated_ /etc/openssl/certs,
   postinstall will fail and ask you to either set `manual' in
   /etc/openssl/certs.conf or move /etc/openssl/certs out of the way.

   This applies to anyone who is currently using mozilla-rootcerts,
   mozilla-rootcerts-openssl, or ca-certificates from pkgsrc, or
   anyone who has, like bouyer@, added any custom entries by hand.

   This will also apply to anyone who had updated to current and run
   postinstall in the time between 2023-08-26 and now, even if they
   hadn't otherwise populated /etc/openssl/certs, so I put a note in
   UPDATING about it.

   (Exception: If for some reason you had created the file
   /etc/openssl/certs/.certctl already, postinstall will quietly blow
   away your /etc/openssl/certs directory, of course.)

4. If you set `manual' in /etc/openssl/certs.conf, postinstall may
   print a message but will not touch /etc/openssl/certs and will not
   fail.

Let me know if any of this seems wrong, or if the implementation seems
to behave differently from what I described.  I added automatic tests
for the various cases of certctl, and I manually tested postinstall
with:

(a) nonexistent /etc/openssl/certs (create and populate)
(b) empty /etc/openssl/certs (populate)
(c) nonempty /etc/openssl/certs (fail)
(c) nonempty /etc/openssl/certs + manual (leave alone and pass)
(d) /etc/openssl/certs with .certctl (delete and recreate)


Regarding etcupdate: I agree that interactive prompting is bad for
deployment.  I don't actually use etcupdate myself, partly because it
is too interactive but mainly because it can't do three-way merges --
instead, I use a bespoke script called etcmerge that does three-way
merges using the old and new etc.tgz.

https://mumble.net/cgit/campbell/etcmerge

(Maybe some day I will propose to import this into base, but it needs
a lot more polish and testing first, and some tweaks to the usage
model which currently has too many things going on at once.)

But while I agree with your criticism of etcupdate, it's what we have
in base and what we recommend in the guide.  So that's what we have to
work with as a baseline to gauge the impact of changes like this on
update procedures; it's hard to meaningfully gauge if I have to guess
everything that anyone might try to do.

That said, you're right that it's better not to create things that
rely on the interactive prompt.