[Bug 1856422] Re: always call mokutil with --timeout -1 when enrolling dkms keys

[Łukasz Zemczak]

The change is good and I'd be willing to accept it, but before I do so I
wanted to consult the SRU version number first. You have used 1.39.1,
but currently 1.39 is present both in eoan and disco. I know disco goes
EOL on January next year, but knowing our bad luck, I'm worried that if
some emergency upload is required, the version number might be
problematic. On the other hand, I guess in this very improbable case we
could just use ~ for disco.

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

Title:
  always call mokutil with --timeout -1 when enrolling dkms keys

Status in shim-signed package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  New
Status in shim-signed source package in Bionic:
  In Progress
Status in ubiquity source package in Bionic:
  New
Status in shim-signed source package in Eoan:
  New
Status in ubiquity source package in Eoan:
  Won't Fix

Bug description:
  [SRU Justification]
  The version of MokManager currently in all releases supports a MokTimeout variable, which can be set with mokutil --timeout, to control how long MokManager waits for input instead of having a hard-coded timeout of 10 seconds.

  If the timeout is reached on boot with no input, MokManager clears the
  MOK requests and passes control back to shim, which falls back to
  booting the OS.

  So if you miss seeing MokManager on boot, you have to restart the key
  enrollment process from the OS and reboot again.

  When we are invoking mokutil automatically on behalf of the user as
  part of key generation for dkms modules, we should disable the
  timeout.  We should never leave the user with broken dkms modules on
  the system because they were looking away from the console at the
  wrong point in time during a reboot.

  [Test case]
  1. On a system with SecureBoot enabled, install the virtualbox-dkms package.
  2. Set a password to use for MOK enrollment.
  3. Reboot.
  4. Observe that there is a countdown on MokManager.  Let the timer expire.
  5. Install the shim-signed package from -proposed.
  6. Purge the virtualbox-dkms and dkms packages.
  7. sudo rm -rf /var/lib/shim-signed.
  8. Repeat steps 1 through 3.
  9. Observe that there is no countdown on MokManager, and that it waits indefinitely for input (confirm that this is the case by sitting at the screen for at least 1 minute).

  [Regression potential]
  If a wrong version of mokutil is called with this additional argument and doesn't support it and as a result mokutil fails, this could result in users not having their MOK enrolled who otherwise would have.

  This prevents systems which have a pending MOK enrollment due to dkms
  from rebooting unattended back to Ubuntu.  If anyone is automating
  configuration of dkms/shim, during an install or otherwise, and
  expecting the system to reboot back to Ubuntu without intervention at
  the console, this will stop working.  However, such a system is broken
  with respect to dkms modules and SecureBoot anyway; the user should
  either not install dkms modules, or plan for handling the MOK request
  at the console (serial console or otherwise) on the next reboot.

  If the user does not have console access to the system but does have
  power access, they can still bypass MokManager by power cycling the
  system, again giving them a system which is booted but does not
  properly support the dkms modules under SecureBoot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1856422/+subscriptions