You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now bootc uses the naive systemd-cryptenroll default PCR selection of 7 when binding a LUKS volume. This is not ideal as shim package updates or version disagreement between installation and installed environment will cause the PCR 7 hash to change thus prevent unlocking of the LUKS root volume.
Beyond the obvious implications that broken boot is a very bad user experience, use of PCR 7 only is not necessarily a best practice when using TPM to unlock encrypted partitions. Users will most certainly need control over the PCR configuration and the systemd-cryptenroll defaults are really not intended as production solutions (they are a rather plain default that might work in some cases).
Either an install configuration or CLI option is needed to allow configuration of the TPM PCRs that the LUKS volume is bound to.
The text was updated successfully, but these errors were encountered:
Right now bootc uses the naive systemd-cryptenroll default PCR selection of 7 when binding a LUKS volume. This is not ideal as shim package updates or version disagreement between installation and installed environment will cause the PCR 7 hash to change thus prevent unlocking of the LUKS root volume.
Beyond the obvious implications that broken boot is a very bad user experience, use of PCR 7 only is not necessarily a best practice when using TPM to unlock encrypted partitions. Users will most certainly need control over the PCR configuration and the systemd-cryptenroll defaults are really not intended as production solutions (they are a rather plain default that might work in some cases).
Either an install configuration or CLI option is needed to allow configuration of the TPM PCRs that the LUKS volume is bound to.
The text was updated successfully, but these errors were encountered: