Using a x230 with default heads 1.3.1, nitrokey inserted and updated checksums, I noticed the following bug:
Navigate the heads menu to → Boot Options → Boot menu
Try to exit the menu again with indicated “a” (abort) key. It won’t work (in my case at least). The only key working appears ESC.
After the main heads menu reappears, it will show a HOTP mismatch.
try updating HOTP/TOTP from the menu, a TOTP mismatch (yellow screen) will appear too.
poweroff and on → all ok again.
It’s reproducible for me. It is not a severe as a bug, but in circumstances the heads alerting (color changes to red after two tries) may misguide a user to reset the TPM or so.
I had a brief search in the forum and on heads’ github, but did not see a related bug, so I drop it here.
Could also reproduce the issue. Traced the behavior as follows:
The menu is being displayed using whiptail. Pressing ESC exits it with error code 255. This leads to executing die. This calls echo with the error message and exits kexec-select-boot with 1.
The parent script then calls show_main_menu at the end of the file which executes unseal-hotp (saved as variable $HOTP) which presumely alters PCR values and the HOTP changes.
while true; do
show_main_menu
done
Potential Fix for a button not working:
After the following line just repeat lines 126-128 where the button a is handled.
This still would alter the PCR values and thus the HTOP. I think this is intentional. The HTOP/TOTP should check whether the boot to menu was not altered. And aborting the boot menu alters the “clean” state.
@nku thanks for the report! In general you could also open an issue here Issues · Nitrokey/heads · GitHub but this way is also fine. I could reproduce the Abort issue in our Firmware 1.4-2-g9c5e572 . But the HOTP Issue I can’t reproduce, So maybe this is a different issue just in 1.3.1. This (HOTP mismatch) actually should not happen, since no file is changed, so it sounds like a bug. When we have a fix I will link it here