group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1856422@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package shim-signed - 1.33.1~16.04.10

---------------
shim-signed (1.33.1~16.04.10) xenial; urgency=medium

  * Update to shim 15.4-0ubuntu7:
    - Fix load option parsing, and thus fwupd execution (LP: #1929471) (PR #379)
    - Fix occasional crashes in _relocate() on arm64 (LP: #1928010) (PR #383)
    - Fix accidental deletion of RT variables (LP: #1934506) (PR #387)
    - mok: relax the maximum variable size check (LP: #1934780) (PR #369)

shim-signed (1.33.1~16.04.9) xenial; urgency=medium

  * Do not build a dual-signed shim (fixing regression from ~16.04.7), and
    disable verifying fbx64.efi and mmx64.efi certificates as xenial's
    sbverify is unable to (impish works fine)
  * Clean up debhelper log file accidentally imported into git during 16.04.7
    import.

shim-signed (1.33.1~16.04.8) xenial; urgency=medium

  * debian/*.postinst: Unconditionally call grub-install with
    --force-extra-removable, so that the \EFI\BOOT removable path as used in
    cloud images receives the updates.  LP: #1930742.
  * Update to shim 15.4-0ubuntu5:
    - Stop addending vendor dbx to MokListXRT during MokListX mirroring. This
      is causing systems to run out of EFI storage space, or just hang up
      when trying to write it (LP: #1924605) (LP: #1928434)
    - Further relax the check for variable mirroring on non-secureboot systems
      avoiding boot failures on out of space conditons (pull request #372)
    - Don't unhook ExitBootServices() when EBS protection is disabled
      (LP: #1931136) (pull request #378)

shim-signed (1.33.1~16.04.7) xenial; urgency=medium

  * New upstream release 15.4.  LP: #1921134
  * Update packaging to pull fb and mm from shim-signed package as in
    later releases, dropping the runtime dependency on shim.
  * Add download-signed script from linux-signed package
  * Add a versioned dependency on the mokutil that introduces --timeout, and
    call mokutil --timeout -1 so that users don't end up with broken systems
    by missing MokManager on reboot after install.  LP: #1856422.
  * Add versioned dependencies on grub-efi-amd64-signed and grub2-common,
    to ensure we have SBAT-compatible grub.efi and grub 2.04-compatible
    grub-install present when we are installing new shim to the ESP.
  * Include reworked Makefile from devel to better assert the integrity of
    the executables.

 -- Julian Andres Klode <juliank@xxxxxxxxxx>  Fri, 16 Jul 2021 13:04:57
+0200

** Changed in: shim-signed (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Fix Released
Status in shim-signed source package in Xenial:
  Fix Released
Status in shim-signed source package in Bionic:
  Fix Released
Status in shim-signed 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