** Description changed: - Currently the firmware-updater GUI verifies the recovery key on updates - affecting TPM/FDE state using a synchronous POST call to the - "/v2/system-volumes" endpoint of snapd. This is for the purpose of - ascertaining the availability of the recovery key before reboot in order - to prevent locking the user out of the system. + [ Impact ] + Currently the firmware-updater GUI verifies the recovery key on updates affecting TPM/FDE state using a synchronous POST call to the "/v2/system-volumes" endpoint of snapd. This is for the purpose of ascertaining the availability of the recovery key before reboot in order to prevent locking the user out of the system. - A proposal was made upstream (see - https://github.com/fwupd/fwupd/issues/9744) to generalize this - verification by moving it into fwupd itself and communicating the - verification to the possible frontends using the system DBus. However - after some discussion it was concluded that this had considerable - security implications and the proposal was discontinued. + [ Test plan ] + 1. On TPM/FDE enabled Ubuntu Desktop system + 2. Using fwupdmgr to update UEFI firmware + 3. A prompt is popped up to request user to input recovery key + 4. The system can finish UEFI firmware update successfully and boot to Ubuntu Desktop + + [ Where problems could occur ] + The recovery key is not stored successfully, and the user is not able to boot into the system anymore. + + [ Additional information ] + A proposal was made upstream (see https://github.com/fwupd/fwupd/issues/9744) to generalize this verification by moving it into fwupd itself and communicating the verification to the possible frontends using the system DBus. However after some discussion it was concluded that this had considerable security implications and the proposal was discontinued. Still, firmware-updater has the behavior of verifying the recovery key, and as such we should reflect this behavior in the fwupdmgr CLI frontend. In the future we should consider not requiring the user to input the recovery key upon predictable reboots, which means that this is likely best maintained as a temporary patched delta in the meantime.
** Description changed: [ Impact ] Currently the firmware-updater GUI verifies the recovery key on updates affecting TPM/FDE state using a synchronous POST call to the "/v2/system-volumes" endpoint of snapd. This is for the purpose of ascertaining the availability of the recovery key before reboot in order to prevent locking the user out of the system. [ Test plan ] 1. On TPM/FDE enabled Ubuntu Desktop system 2. Using fwupdmgr to update UEFI firmware 3. A prompt is popped up to request user to input recovery key 4. The system can finish UEFI firmware update successfully and boot to Ubuntu Desktop [ Where problems could occur ] - The recovery key is not stored successfully, and the user is not able to boot into the system anymore. + The recovery key is not written to snapd successfully, and the user is not able to boot into the system anymore. [ Additional information ] A proposal was made upstream (see https://github.com/fwupd/fwupd/issues/9744) to generalize this verification by moving it into fwupd itself and communicating the verification to the possible frontends using the system DBus. However after some discussion it was concluded that this had considerable security implications and the proposal was discontinued. Still, firmware-updater has the behavior of verifying the recovery key, and as such we should reflect this behavior in the fwupdmgr CLI frontend. In the future we should consider not requiring the user to input the recovery key upon predictable reboots, which means that this is likely best maintained as a temporary patched delta in the meantime. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2138609 Title: Patch fwupdmgr to verify recovery key with snapd API for TPM/FDE To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/2138609/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
