[Bug 1695578] [NEW] shim-signed trigger should not fail when attempting to re-prompt noninteractively and we've prompted before
Steve Langasek
steve.langasek at canonical.com
Sat Jun 3 05:15:52 UTC 2017
Public bug reported:
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.
** Affects: shim-signed (Ubuntu)
Importance: Critical
Assignee: Mathieu Trudel-Lapierre (cyphermox)
Status: Triaged
** Changed in: shim-signed (Ubuntu)
Importance: Undecided => Critical
** Changed in: shim-signed (Ubuntu)
Status: New => Triaged
** Changed in: shim-signed (Ubuntu)
Milestone: None => ubuntu-17.06
** Changed in: shim-signed (Ubuntu)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
--
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/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:
Triaged
Bug description:
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
More information about the foundations-bugs
mailing list