Re: new certificate stuff

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

> Date: Mon, 28 Aug 2023 06:30:05 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Maybe this is too much, but perhaps certctl should look for a .certctl
> in /etc/openssl/certs and only if present rm/replace.  Or really only
> limit the rm; adding to an empty dir is fine.   Basically a token that
> says the dir is under the control of certctl.  -f can override the
> check and write the token.

How is using /etc/openssl/certs/.certctl as the token different from
using /etc/openssl/certs.conf as the token?

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,

and

(b) on _future_ updates (like 10.0 to 10.1, where both releases have
    certctl(8) and a default certs.conf), /etc/openssl/certs gets
    updated too (unless you set `manual' in /etc/openssl/certs.conf).


Please be specific either about what mechanism you mean and how it
meets these criteria, or about scenarios that you think the current
mechanism will inadequately address.


The status quo in HEAD (if pulled up to netbsd-10) will be:

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

2. Updates to existing installations that follow the long-standing
   procedure of

   - update kernel
   - unpack non-etc sets
   - run etcupdate
   - run postinstall

   will interactively prompt during etcupdate to install the new
   /etc/openssl/certs.conf.

   The file has comments explaining what it does and how to override
   it -- here's the current content:

      netbsd-certctl 20230816

      #       $NetBSD: certs.conf,v 1.1 2023/08/26 05:27:15 riastradh Exp $
      #
      # Configuration file for certctl(8) to manage HTTPS root CA
      # certificates in /etc/openssl/certs.
      #

      path    /usr/share/certs/mozilla/server

      # For manual control over /etc/openssl/certs, e.g. if you want to
      # install a separate CA bundle from pkgsrc, uncomment the next line:
      #manual

   If the user declines to install /etc/openssl/certs.conf in
   etcupdate, then postinstall will print a message about failing to
   open it.  (postinstall should also fail with nonzero exit code in
   this case -- bug to be fixed.)

3. If:
   - you have /etc/openssl/certs.conf from 10.0,
   - you haven't set it to manual,
   - there are changes to mozilla-certdata from 10.0 to 10.1, and
   - you update to 10.1,
   then those changes will be reflected in /etc/openssl/certs on
   postinstall (but etcupdate won't prompt anything about certs.conf
   -- unless something has also changed in that, of course).

4. If you _don't_ have /etc/openssl/certs.conf from 10.0 (you deleted
   it or you never let etcupdate create it), and you update to 10.1,
   then it's the same deal as (2).

If you follow a different procedure for update, like naively unpacking
etc sets or running a bespoke etcupdate replacement, well, you should
expect to have to deal with the fallout yourself.