So my #arch#linux just catastrophically self-destructed. I was using arch with the yubikey full-disk encryption package, when the machine hung and crashed during a system update. The machine crashed exactly after the old initramfs files were cleaned up, and before the new ones were written to disk. Since the yubkikey fde thing stores the seed ("challenge") for the luks key in the initramfs, all copies of the seed are gone now, and the data on that disk is unrecoverable.
Quite the failure mode if you ask me. I guess I will be scraping that yubikey fde thing from all of my machines now, and go back to plain passphrases. Deleting the old seed files before the new ones have been written and flushed to disk is a pretty bad design error.
@jaseg that's super shit. it should really be writing the new seed, issuing a sync, purging the disk I/O cache, doing readback and verifying that it was written correctly, marking that new seed as primary and the old seed as ready for deletion, then only actually deleting that old seed once you've rebooted and successfully authenticated to the new seed. that way you always have the option to roll back, right up until you've successfully used the new seed.
Update to the update: The creators of the #arch#linux yubikey full disk encryption thing have responded to my bug report with what is essentially a shrug emoji and the line "I hope you had [a backup]".
I don't think that's an appropriate reponse from the maintainers of a critical piece of software like this. I think if you choose to release software like this, you have a responsibility to either make it good or to at the very least warn users that it's bad.
@jaseg after reading it, it sounds like a good and correct answer to me. The real problem here is mkinitcpio deleting the initramfs after creating the new one. Also, his answer about having a warning at the readme about making a backup seems right to me. But doing it automatically in a hardcoded path doesn't sound good to me.
@EA8DHY If they can't figure out the path automatically, just prompt the user.
With the mkinitcpio thing, I don't have the time to take on that fight. For me it doesn't matter if it's their tool or their upstream, the end result is the same: Their tool can't be used safely.
I believe they have the best intentions, but unfortunately the result sucks despite those good intentions.
@jaseg
I ran Arch for four months recently. Even the Arch maintainers themselves describe it as a distribution building kit, not a distribution, and they're not wrong.
Using it was a fun experience and mostly very pleasant. But it made it crystal clear to me nobody should run plain Arch on a machine that would cause issues if it was suddenly lost.
If I had to choose between Arch and yubikey, I'd pick yubikey.
@waldi it uses the yubikey in challenge-response mode instead of plain password mode so you can't read the luks passphrase out of the yubikey without the computer.
@jaseg LUKS allows for multiple slots to be defined, I think 8? So you can have it be automatically unlocked by yubi, but you can also have a separate password to unlock it, for situations like this.
Yes, this situation sucks. This is meant as a hint how you can protect yourself in the future.
@psotle@viq I have a backup for cases like physical damage or loss to the hardware key. That I have to resort to that backup because of an avoidable snafu like this is lame.
Add comment