group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1695578@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package shim-signed - 1.32~17.04.1

---------------
shim-signed (1.32~17.04.1) zesty; urgency=medium

  * Backport shim-signed 1.32 to 17.04. (LP: #1700170)

shim-signed (1.32) artful; urgency=medium

  * Handle cleanup of /var/lib/shim-signed on package purge.

shim-signed (1.31) artful; urgency=medium

  * Fix regression in postinst when /var/lib/dkms does not exist.
    (LP#1700195)
  * Sort the list of dkms modules when recording.

shim-signed (1.30) artful; urgency=medium

  * update-secureboot-policy: track the installed DKMS modules so we can skip
    failing unattended upgrades if they hasn't changed (ie. if no new DKMS
    modules have been installed, just honour the user's previous decision to
    not disable shim validation). (LP: #1695578)
  * update-secureboot-policy: allow re-enabling shim validation when no DKMS
    packages are installed. (LP: #1673904)
  * debian/source_shim-signed.py: add the textual representation of SecureBoot
    and MokSBStateRT EFI variables rather than just adding the files directly;
    also, make sure we include the relevant EFI bits from kernel log.
    (LP: #1680279)

shim-signed (1.29) artful; urgency=medium

  * Makefile: Generate BOOT$arch.CSV, for use with fallback.
  * debian/rules: make sure we can do per-arch EFI files.

 -- Mathieu Trudel-Lapierre <cyphermox@xxxxxxxxxx>  Mon, 10 Jul 2017
17:10:08 -0400

** Changed in: shim-signed (Ubuntu Zesty)
       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/1695578

Title:
  shim-signed trigger should not fail when attempting to re-prompt
  noninteractively and we've prompted before

Status in shim-signed package in Ubuntu:
  Fix Released
Status in shim-signed source package in Trusty:
  Fix Committed
Status in shim-signed source package in Xenial:
  Fix Released
Status in shim-signed source package in Yakkety:
  Fix Committed
Status in shim-signed source package in Zesty:
  Fix Released

Bug description:
  [Impact]
  Users may require updates to DKMS modules while shim validation is disabled, and expect to do these updates non-interactively, such as via unattended-upgrades.

  [Test Case]
  == Interactive ==
  (on an EFI system with proper Secure Boot support)
  1- Install an old version of a DKMS package (such as bbswitch-dkms or r8168-dkms)
  2- Follow the prompts on install to disable shim validation; reboot.

  The system should allow you to install the dkms module and prompt you
  for a password to disable Secure Boot validation in shim. This
  behavior should remain the same with or without the patch and serves
  as an extra verification to guard against regressions.

  == Uninteractive ==
  (on an EFI system with proper Secure Boot support)
  1- Install an old version of a DKMS package (such as bbswitch-dkms or r8168-dkms)
  2- Follow the prompts on install to disable shim validation; reboot.
  3- Run 'sudo apt update'
  4- Enable unattended-upgrades (see https://help.ubuntu.com/lts/serverguide/automatic-updates.html)
  4b - If necessary, using PPA packages for testing, allow the PPA source in /etc/apt/apt.conf.d/50unattended-upgrades.
  5- Wait/trigger unattended upgrades; observe the behavior:

  The user has not installed any new DKMS modules, and we're
  noninteractive, the trigger should silently pass. Without the patch,
  this test case should fail (upgrade fails) because update-secureboot-
  policy is unable to prompt the user.

  == New DKMS package install uninteractively ==
  1- Enable unattended upgrades
  2- Prepare a new PPA package update that adds a dependency on a -dkms package.
  3- Wait/trigger unattended upgrades; observe the behavior.

  The user is in effect installing a new DKMS module that was not
  already present on the system and being upgraded. In this case, the
  upgrade should fail, because update-secureboot-policy is unable to
  prompt the user. Without the patch, the same behavior occurs (this
  serves as another regression guard)

  [Regression Potential]
  Failure to complete an update in non-interactive (unattended-upgrades) when DKMS modules are in use, triggering a failure in apt's upgrade process would be a regression of this update. Also, being unable to correctly recognize the current state of Secure Boot and shim validation, or incorrectly returning before prompting for the password required to toggle shim validation when the shim validation state make sense to be changed (ie. prompting to enable when it is disabled only, prompting to disable only if it's currently enabled).

  [Background information]
  The upgrades should run non-interactively without issue whenever possible, but forcefully prompt the user if a new DKMS package is being installed uninteractively:

   - If the user installs a new DKMS module, we should not silently proceed.  Either the user should be prompted, or if we're noninteractive, the trigger should fail.
   - If the user has not installed any new DKMS modules, but we have an interactive frontend, we should prompt.
   - If the user has not installed any new DKMS modules, and we're noninteractive, the trigger should silently pass.

  ---

  We currently always fail with an error when update-secureboot-policy
  has been called, we detect that secureboot needs to be disabled for a
  dkms module, and we don't have an interactive debconf frontend.
  However, as a result this means that if the user has previously made a
  conscious decision *not* to disable secureboot, despite having dkms
  modules installed, a non-interactive package upgrade will fail.

  It doesn't make sense for a non-interactive package upgrade to fail
  merely because the user's secureboot setting is ill-advised.

  We should ensure that:

   - If the user installs a new DKMS module, we should not silently proceed.  Either the user should be prompted, or if we're noninteractive, the trigger should fail.
   - If the user has not installed any new DKMS modules, but we have an interactive frontend, we should prompt.
   - If the user has not installed any new DKMS modules, and we're noninteractive, the trigger should silently pass.

  To know whether new DKMS modules have been installed, we should
  capture the list from /var/lib/dkms and store it under /var/lib/shim-
  signed on each successful invocation.

  For upgrade purposes, the shim-signed postinst should detect that we
  are upgrading from a version of the package that did not yet record
  the list in /var/lib/shim-signed, and record any DKMS modules present,
  so that these are not considered "new".  We only want to do this on
  upgrade, not on a new install of shim-signed; on a new install, the
  trigger should already handle this for us.

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