Package: shim-signed Version: 1.51~1+deb13u1 Severity: normal Tags: trixie Dear Maintainer,
The latest shim update for Trixie caused me significant grief with respect to TPM-backed decryption keys. I have a number of systems with LUKS-encrypted root volumes which store the decryption key in the TPM to permit unattended remote unlock. The TPM is sealed against a number of PCRs; if I were to guess PCR7 is the one of interest here. The latest apt patchset contained an update to shim, which quietly invalidated the PCRs. This caused all hell to break loose upon reboot. UEFI Secure Boot is enabled on these systems. PROBLEM: The issue is that shim was updated quietly and without explicit warning to the user, but the changes were disruptive. The issue is not in shim itself but the package handling at Debian level. Upon reboot, the TPMs refused to release the keys so I now had numerous machines hung during boot waiting for passwords to unlock the root volume. I lacked serial access to most of these systems so it required unpleasant visits to the consoles to unlock the systems then re-enroll the keys to the TPM. You could argue everything worked as designed, but the impacts of a routine 'apt upgrade' were severe and I did not realize what happened until it was too late. SUGGESTION: I suggest at minimum an apt-listchanges type warning when shim is updated on stable, for the potential need to re-seal the TPM before reboot. But in reality this problem should be solved with a holistic view of the Debian system. Is this a bug in shim? Not exactly. It's also not a bug in apt nor systemd because all the components work as designed in isolation. But put together there was a bit of a perfect storm where a routine apt invocation left me with unbootable systems. Regards Lloyd
