RFC : Follow up to PGP auth: what should be blocked

[tlaurion]

Work is getting near merging state under #2158

A user could still flash an evil-maid firmware unauthenticated to bypass authentication.

Up to now (before authentication keys being able to be restored on new smartcard received when lost) per #2158

So attack surface is now:

• got to system info, capture commit id of good firmware
• flash new evil maid firmware
• not reseal secrets, got to recovery shell
• backup firmware, giving keyring, trustdb and config.user override
• create havoc if needed (DoS: wipe os install)
• create reproducible build for known good commit, reflash that rom
• on reboot, totp/hotp good, but havoc created

What do we want here? prevent flashing when user has gpg priv key backup (so lost usb dongle is not bricking access?) or should we stay more liberal vs more secured? @JonathonHall-Purism @nestire ?

[tlaurion]

Next step might be dicuss under #1520 for "restricted boot" changes and what we want to be the "default" policy under heads not enforcing "restricted" but default Heads boot policy (gui-init.sh)

That is the last, outside of qemu QA, thing i wanted to redress of Heads vs the state I started to work on it in 2018. After that my work will go https://osresearch.net/Consultation-Services/ outside of maintenance, since I feel I can now become redundant if #2027 lands with co=responsibilities: I should not be expected to maintain heads for free as in free beer forever, right?