Re: new certificate stuff

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

Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

> Currently, if /etc/openssl/certs.conf doesn't exist, `certctl rehash'
> (the crux of `postinstall fix opensslcerts') will print an error
> message and then exit with status 0.  This combination is a bug --
> need to think a bit about it, but probably better to exit nonzero than
> to suppress the error message.

sure, that's fine.

> So if you unpack new _non-etc_ sets, `postinstall fix' won't
> clobber your /etc/openssl/certs directory.

ok

> The etc.tgz set, however, will have /etc/openssl/certs.conf.  So if
> you naively unpack etc.tgz, `postinstall fix' will clobber your
> /etc/openssl/certs directory.

What I do is unpack etc.tgz and xetc.tgz to /usr/netbsd-etc and then use
etcmanage, which does automatic updates which are safe.  However, safe
is not turing complete; it is "this file has newly appeared in the new
etc and does not exist in the real etc so copy it in".  This happens all
the time with new rc.d and things like that.

> That said, I think if you use etcupdate(8), it will interactively
> prompt you before creating the new /etc/openssl/certs.conf.  (Have
> made a note to add this in my etcmerge(8) tool to do a three-way merge
> for updating (x)etc sets too.)

etcmanage won't prompt.  It has a different design philosophy, which is
that it is run non-interactively to allow administering large numbers of
computers.  The initial impetus was a testbed of 20 and later 100.  So
it does what can be done safely and just doesn't do the rest, which
works out remarkably well.

ANd the prompt is not

  this is installing a config file that will cause later steps to
  overwrite manual configuration

it's just

  there's a new config file you don't have; install it?



> I'm open to other suggestions about how to handle the transition from
> manually maintained /etc/openssl/certs on (say) 9.x with no certs.conf
> or certctl(8) to 10.0 with new default certs.conf and certctl(8),
> provided that
>
> (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).

I think the only issue is a one-time transition from

  sysadmin controls contents of /etc/openssl/certs

to

  certctl controls contents

and I can't think of anything safe other than

  sentinel file in /etc/openssl/certs declares it certctl managed

  certctl will auto-write the sentinel if it's sure there are no manual
  contents

  certctl will rm/replace if sentinel present

  certctl -f will rm/replace and write sentinel



This works for (a) and it works for (b), with postinstall fix because
there is a sentinel file, and it will also work if certs.conf gets
updated via etcupdate/etmanage/etcmerge/whatever-sysadmin-uses.