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

[Steve Langasek]

** Also affects: ubiquity (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: ubiquity (Ubuntu)
       Status: New => Triaged

** Changed in: ubiquity (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity 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:
  Triaged
Status in shim-signed source package in Bionic:
  Fix Committed
Status in shim-signed source package in Eoan:
  Fix Committed

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