Comment 0 for bug 1896509

Revision history for this message
dann frazier (dannf) wrote :

[Impact]
Currently if you install clevis-initramfs, it will always try to bring up networking even in cases where it is unnecessary. It's not necessary if, say, the volume is to be unlocked via TPM, or perhaps no pin at all and clevis just happens to be installed. In those cases, the user is stuck waiting for configure_networking() to finish before they get prompted for a passphrase,
and that will take nearly 5 minutes to timeout if the system is offline. It is also not clear to users that it *will* eventually timeout, which they may interpret as leaving their system unbootable w/o a network connection.

[Test Case]
- Regression test a system that is online and uses a tang pin.
- Test a system using a tang pin that is offline, and confirm the user is prompted with a passphrase prompt without delay.
- Test a system that does not use a tang pin and verify that network config is not attempted.

[Fix]
Backport of this upstream patch series:
https://github.com/latchset/clevis/commit/adaef407265479cd1067c4fbf69fdaa0dd6ae586
https://github.com/latchset/clevis/commit/ee369808473945165a3f3b79a52c1d10f29eb5c4
https://github.com/latchset/clevis/commit/780eb30986323613f5b192c03c881caecae8cd7b

[Regression Potential]
If the tang pin detection is buggy, it's possible that systems will fail to auto-unlock using a tang server. It's also possible (but seemingly unlikely) that users have been relying on network access in the initramfs as a side-effect of having clevis installed, and that could no longer be the case if clevis determines it is not necessary for its own purposes.