** Description changed: + [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. + + == 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) + 5- Wait/trigger unattended upgrades; observe the behavior. + + == 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 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. + + + [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). + + --- + 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. + - 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1695578/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
