Make TPM-based encryption more explicit

[ancorgs]

Problem

Sometimes, Agama decides to use the encryption method TPM_FDE which results in the system being configured via fde-tools to open the encryption devices automatically during system boot without needing to enter the password.

That happens if the configuration parameter encryption.tpm_luks_open is set AND the system supports TPM unlocking. If that the case, the TPM_FDE encryption method is used without even asking the user. In any other case, the encryption method specified at the configuration parameter encryption.method is used.

That's all quite obscure, the users don't know whether TPM-based unlocking is going to be configured. Not even if it's possible to configure it or not.

Solution

This pull request introduces some changes in how the whole thing is managed.

Now if the system or the distribution being installed don't support TPM-based decryption, the encryption method LUKS2 is used and nothing is shown in the UI.

So no big change for the user except the fact that now LUKS2 with PBKDF2 as derivation function is the default for all distributions (it's a pretty sensible default for distributions based on Grub2 at 2024).

But if the system and the distribution both support to configure TPM-based opening of the LUKS devices, the user can choose between the TPM_FDE and the LUKS2 encryption methods via a checkbox shown in the UI.

The default encryption method (and thus, the default value of the checkbox) is configured per-product at encryption.method. If the value there is "tpm_fde" but the system does not support such a method (eg. there is no TPMv2 chip), Agama will use the default encryption method (LUKS2) as fallback.

Additionally, to make sure the user does not overlook the need to boot the machine directly to the new system in order to complete the setup, the following warning has been added to the page at the end of the installation process.

Expanded version:

Of course, if TPM encryption was not used, the hint is not there.

Testing

• Tested manually
• New unit tests for the InstallationFinished page
• No tests added to the storage page, since it's going to heavily change soon

[coveralls]

coverage: 74.865%. remained the same
when pulling 432b5b4 on tpm_fde_ui
into 35740d4 on master.

[dgdavid]

As I wrote in the commit message, following here the same approac as the current network code. We could, however, goes for what we did with client/phase or client/status instead and move it to a client/storage-encryption-methods.js or client/storage/encryption-methods.js

export const LUKS2 = "luks2";
export const TPM = "tpm_fde";

export default {
  LUKS2,
  TPM
};

and then import needed values

import { TPM } from "~/client/storage/encryption-methods"

import * as EncriptionMethods from "~/client/storage/encryption-methods"

No strong/clear opinion. Something to think about for future enhancements.

[joseivanlopez]

NP: this condition should be already covered by #include?.

[joseivanlopez]

Please, add changelog.

[dgdavid]

BTW, today I learned that another option for doing this might be to add a helper function in test-uitls. Something like slowDown, smallWait or whatever other name suits better

const shortBreak = async (ms = 500) => new Promise(resolve => setTimeout(resolve, ms));

and then in the test

import { shortBreak } from "test-utils";

...

await shortBreak();

I haven't tested it, just got inspiration from react-spectrum

[joseivanlopez]

LGTM