update database on each boot, not just on package install

[Steve Langasek]

[Impact]
Currently the secureboot databases are only updated at the time the secureboot-db package is installed or upgraded, but this may not be the point in time that the firmware needs to be updated.

- New OS install: the secureboot-db package was installed during the image mastering, not when Ubuntu is written to the target disk.
- Package installed while the system is booted in BIOS mode, later switched to UEFI mode
- Hard drive moved to a new computer which doesn't yet have the updates

We should ship a systemd unit to re-apply these revocations as necessary on each boot.

The unit should be
ConditionPathExists=/sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f

(don't use dbx for the condition, since if dbx is empty this variable may be absent.)

[Test case]
- Ensure unit runs at boot
- Ensure unit runs in postinst on upgrade

[Regression potential]
Biggest potential is in the postinst, which now relies on dh to start the systemd oneshot service, rather than doing all the work itself. So if that's not working, things might act differently.

Regression potential at boot is barely existent. If the service fails, nothing bad happens except your system booting in degraded state. There might be a minor slow down, but should not be much.

[Julian Andres Klode (juliank)]

Patch for review

[Julian Andres Klode (juliank)]

Actual patch.

[Steve Langasek (vorlon)]

Patch lgtm.

[Launchpad Janitor (janitor)]

This bug was fixed in the package secureboot-db - 1.5

---------------
secureboot-db (1.5) eoan; urgency=medium

  * Add secureboot-db.service to apply updates at boot (LP: #1791370)
  * Delete postinst script, as systemd service is started postinst by dh

 -- Julian Andres Klode <email address hidden> Mon, 08 Jul 2019 17:36:02 +0200

[Steve Langasek (vorlon)]

This is a low-priority bug and I had no expectation that this change needed to be SRUed into stable releases. Introducing a systemd unit is relatively high risk for an SRU because of its potential impact on boot speed/timing/ordering. I am declining this as an SRU.

[Steve Langasek (vorlon)]

An upload of secureboot-db to disco-proposed has been rejected from the upload queue for the following reason: "Not necessary or appropriate to SRU".

[Steve Langasek (vorlon)]

An upload of secureboot-db to bionic-proposed has been rejected from the upload queue for the following reason: "Not necessary or appropriate to SRU".

[Steve Langasek (vorlon)]

An upload of secureboot-db to xenial-proposed has been rejected from the upload queue for the following reason: "Not necessary or appropriate to SRU".