Heads prompts for non-existent TPM disk unlock password after LUKS container re-encryption

[UndeadDevel]

Please identify some basic details to help process the report

A. Provide Hardware Details

Nitropad NV41 with iGPU and Nitrokey 3A Mini using HOTP.

B. Identify how the board was flashed

Flashed at OEM with Heads 2.1, not updated so far.

C. Identify the rom related to this bug report

Nitrokey Heads 2.1 maximized.

Please describe the problem

Describe the bug
After doing to the re-encryption of the LUKS container via the Heads GUI, Heads now asks me for a TPM disk unlock passphrase that I never set; it didn't do so before. Boot does proceed normally when skipping that, though, so it's just a minor inconvenience.

To Reproduce
Steps to reproduce the behavior:
Without having set up a TPM disk unlock passphrase:
Do the LUKS container re-encryption and try to boot into the OS again.

Expected behavior
Doesn't ask for TPM disk unlock passphrase as before.

[UndeadDevel]

When setting a new default boot option in Heads yesterday, I noticed that it doesn't actually ask me to set a TPM Disk Unlock passphrase at all. I also did a TPM reset and made sure that I only have a LUKS key in keyslot 0, but that didn't help.

Is this feature (TPM Disk Unlock Key) available already on NitroKey Heads 2.1 (commits from here until ~June 2023)? If not, then it seems the bigger problem here is that the feature is broken and not just that there is a useless prompt.

[tlaurion]

Nitrokey release chose their own subset of features to be pushed on their user which might be different then master.

As librems, nitrokey decided to disable the feature for their users.

This is disabled bmin board config which can be confirmed through recovery shell by typing env rhere.

See https://github.com/Nitrokey/heads/blob/42ac4b9cb7589a16f8e6844d854e1c274e42bf04/boards/x230-hotp-maximized/x230-hotp-maximized.config#L75

This specific nitrokey "bug" should be reported to nitrokey. I added the fix in the PoC branch for cryptsetup version bump but my tests are not complete yet to be merged at the same time. I could push a fix to remove the tracing file that cause the issue you reported here initially. There is no reason to create that file anymore in newer heads anyway, LUKS partitions are discovered and proposed to the user. Nothing else then setting a TPM DUK slot should add that file and that is a bug needing fixing. It's not because you reencrypt a disk that you use TPM DUK.

Will fix independently of newer cryptsetup version bump.

[UndeadDevel]

This is solved for me now that NK has enabled the TPM DUK function in their 2.4 release. Though I have not tested if this issue would still occur in the case that a TPM is not set up. Feel free to close if new versions don't have this bug anymore.