Created attachment 130779 [details] screenshots during install SUMMARY Calamares unlocks / with a key file, even if /boot is intentionally unencrypted. Not sure if this is a bug in Calamares or the setup that KDE Neon uses. I think the error is in the expectation that /boot is encrypted as well, in which case a key file for / is useful. But when /boot is unencrypted, this is an rather severe error. STEPS TO REPRODUCE Install KDE Neon with the following setup: 1. Select "Manual partitioning" 2. Select "New Partition Table" and choose MBR 3. Create new partition of size 1024 MiB, Primary, File System Ext4, Mount Point /boot. 4. Create new partition of remaining size, Primary, File System btrfs, Encrypt, Mount Point /. 5. Next 6. Read message about GPT 7. Read message about separate boot with encrypted root. 8. Fill out Users form. Do not login automatically. 9. Install. 10. Reboot. OBSERVED RESULT A luks device is created and a single slot is filled at the beginning of the installation, when the disks are prepared. At the end of the installation, there are 2 key slots in use and there is a definition for decryption of / with a key file in /etc/crypttab. After a reboot, / is automatically decrypted. EXPECTED RESULT A luks device is created and a single slot is filled at the beginning of the installation, when the disks are prepared. At the end of the installation, there is still only 1 key slot in use. After a reboot, after grub and loading the kernel and initramfs, there is a prompt for my password. SOFTWARE/OS VERSIONS Linux/KDE Plasma: neon-user-20200810-1423 (available in About System) KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.72.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION I'm not sure how initram is able to get the key file, seeing how the decryption key for root is also on root.
It is possible the following is related, in which case I would like a big fat warning that it is not only less secure but completely insecure: https://github.com/calamares/calamares/issues/1311#issuecomment-579741764 Right now it is written in a way to make people aware of the evil maid attack (which is fine by me, because if somebody steals my laptop I woun't be able to type in my password anyway), not the "we put the decryption key in the initram so your encrypted root is useless unless you encrypt your /boot as well". Why would you even put your decryption key in initram by default? Is a workaround for now to remove the entry from /etc/crypttap and remove the key from initram?
Luckily this was fixed upstream in the meantime.