[Bug 2037869] Re: ssl-cert should (re)generate /etc/ssl/private/ssl-cert-snakeoil.key on first boot

[Steve Langasek]

Note that the casper script in question is also buggy if the user is
booting with persistence enabled, as the ssl certificate will be
regenerated on every boot.

In contrast, /etc/machine-id is an empty file in all of our live images
(.... but I can't figure out HOW because I see no code for this in
livecd-rootfs!), so a first-boot systemd unit would run each time a live
image is booted without persistence, but if using persistence
/etc/machine-id would be populated in the persistence layer the first
time and the ssl cert would not subsequently be regenerated.

Also, as a side effect, fixing this properly will cause the desktop live
images to boot a smidge faster because they're not running an entropy-
dependent single-threaded operation in the initramfs and can instead run
it a little bit more parallelized from the rootfs (or maybe it will be
faster because there's more entropy available at that point)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to casper in Ubuntu.
https://bugs.launchpad.net/bugs/2037869

Title:
  ssl-cert should (re)generate /etc/ssl/private/ssl-cert-snakeoil.key on
  first boot

Status in casper package in Ubuntu:
  New
Status in ssl-cert package in Ubuntu:
  Triaged
Status in casper source package in Mantic:
  New
Status in ssl-cert source package in Mantic:
  Triaged

Bug description:
  casper has a script, 22sslcert, whose purpose is to regenerate the
  default snakeoil certificate on boot of a live system.  This was done
  to fix bug #337723, which reported that the snakeoil SSL certificate
  (and private key!) was the same on all live systems booted from the
  same image.

  The rationale given in the bug for wanting a different key on each
  system is not entirely correct; it claims the certificate is used for
  "browsing over https", which is not so.  And the ssl-cert package is
  included in the live images for all desktop flavors because it's a
  dependency of cups-daemon, which is in desktop-common; but cups-daemon
  does not use this keypair, instead generating its own on demand (since
  2017).  However, there are other packages that are not part of the
  default desktop environment and may be installed by the user
  afterwards that reference this key (postfix is one), so we shouldn't
  have the same "private" key on all installed systems.

  The casper script fixed this for the live environment, and ubiquity
  also includes code to wipe it from the target system.  But subiquity-
  based installs don't do this - because they populate the target system
  from the read-only squashfs, not from the live environment - and I
  think OEM installs also fail to do this because the ubiquity code in
  question isn't part of oem-config, so the "private" key may be unique
  to the preinstalled system but will also definitely have been exposed
  to the OEM in the factory.

  An option for implementing this consistently might be to have the ssl-
  cert package ship a systemd unit with ConditionFirstBoot=yes.  This
  will be a no-op when installing the package on a system that has
  already been installed, but would allow both live environments and
  newly-installed systems to regenerate the snakeoil key when
  /etc/machine-id is not yet initialized.  (To be determined if this
  satisfies the OEM install case, where /etc/machine-id might be
  populated before the end-user takes ownership.)

  This would then let us drop the code in casper as redundant and
  instead keep the logic local to the responsible package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2037869/+subscriptions