Installing with full disk encryption when using a non-English keyboard layout results in difficulties unlocking the disk

[Aaron Rainbolt]

Steps to reproduce:

1. Boot the Lubuntu Lunar Final ISO.
2. Launch Calamares and set the language to "Spanish (Mexico)".
3. Proceed through the installer until you get to the partitioning screen.
4. At the partitioning screen, enable encryption and type a passphrase that includes a double-quote symbol.
    - On a Spanish keyboard the double-quote symbol is on the same key as the @ symbol on an English keyboard. So if you have an English keyboard, type a passphrase like P@ssphrase1 or something.
5. Finish the installation process.
6. Reboot.
7. Attempt to enter the disk passphrase exactly as you had entered it into Calamares.

Expected result: The disk should unlock and Lubuntu should boot.

Actual result: An "access denied" error is shown and you are dropped to a "grub rescue>" prompt. You can unlock the disk if you reboot and type the passphrase, but using the English double-quote rather than the Spanish one. (For instance, if you have an English keyboard, you would have typed P@ssphrase1 into Calamares but would then have to type P"ssphrase1 to unlock the disk.)

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
https://iso.qa.ubuntu.com/qatracker/reports/bugs/2016912

[Simon Quigley (tsimonq2)]

Yeaaaahp, the decision is that we're going to be switching back to unencrypted /boot for 24.04, since Plymouth supports different keyboard layouts (and actually just uses the default one).

[sudodus (nio-wiklund)]

Will unencrypted /boot make it easier to launch an evil maid atack?

In that case, we can tell people to use only standard ASCII characters in the passphrase, and make the system accept only such characters (in the passphrase).

[Simon Quigley (tsimonq2)]

Hey sudodus, I realize I didn't explain myself very well!

This decision is after a *lot* of discussion and back/forth from Foundations and Security where we asked all these questions in detail. The specific person I spoke with has 20 years of experience with Linux Security (and the other is a GRUB maintainer).

The benefit of having *full* disk encryption is the idea of increased security. That's about it. The security impact is actually negligible, encrypted /boot takes 3x longer to boot, it doesn't have support for other keyboard layouts, and the icing on the cake is that we're actually relying on GRUB's built-in encryption algorithms, which aren't checked for vulnerabilities.

To quote the incredibly experienced member of the Security Team:
> IMHO it's hard to see value from encrypting the boot process: an attacker could replace either one just fine, right? That's where the signatures come in, but that really only helps if the measurements contribute to unsealing a key for the rest of the data, and I'm not sure that's really there for most platforms yet

If there's anything we failed to consider here, please say so. I just think, unfortunately we've had the wrong defaults for a while. Let me know if you have any questions.

[sudodus (nio-wiklund)]

I understand that you have spent time and effort to choose the right method; I'm happy with your decision.

[Simon Quigley (tsimonq2)]

And I'm quite happy to provide followups and more information if I'm ever unclear. :)

Thank you for raising the point!

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

I assume "switching back to unencrypted /boot" means just tweaking our Calamares settings.

[Aaron Rainbolt (arraybolt3)]

This is already fixed for all Calamares-using flavors. Switching to unencrypted /boot and doing some trickery in the Calamares configuration did the trick if I remember correctly. I simply forgot to close this bug :P