> Date: Mon, 28 Aug 2023 08:42:58 -0400 > From: Greg Troxel <g...@lexort.com> > > Taylor R Campbell <riastr...@netbsd.org> 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.
