Am 05.12.19 um 23:02 schrieb Chris Murphy:
read "LUKS by default"
https://pagure.io/fedora-workstation/issue/82

If you read the whole thing, you should come to understand why the
initial agreement to implement full disk encryption was suspended, and
also that this issue has a history proving it is being taken seriously
and deliberately.

First paragraph:

"Figure out the scope - presumably workstation only since servers and cloud VMs need to boot unattended. But perhaps not desktop VMs?"

VM's in the masses areĀ  not installed via anaconda.
One VM is installed via anaconda, and the rest is a clone of the image produced by the install and later setup.
Thats how cloudservers are born ;)

If the vm is paravirtualized ( i.e. Xen ) you can't even enter a plymouth password to unlock a drive. Even if the VM would be encrypted and running in QEMU, which would use up a lot of cpu power, it's still not safe. Same as with the partly encryption of homedirs in homed is insecure, only encrypting the vm is insecure too, due to the mastersystem being able to intercept anything send to the vm. If someome tampered the host, the guest encryption is null and void. If the host is encrypted, there is no longer a need to encrypt the vm.

"
Figure out intersection with current work to use the TPM to allow booting to GDM without entering the password."

Means, if someone steals the device, he can boot a system. Even if we assume that the systemcode is safe and there is no way to interrupt the bootprocess, we are now able to attack the login, which will be much easier than the encryption key, which is massive compared to the passwords in use.

So, NO: no booting without someone entering something.

Besides the already spoken out point, that not all users want encryption, because it takes into consideration to manage an additional passcode,
the entire discussion here was about "encrypt everything, or nothing, because partly does not help at all".

BTW:

"catanzaro commented a year ago Also: tablets need an OSK to be able to decrypt the disk."

Add: grub needs an OSK too, or how do you select the matching kernel?

Skipping the rest of it, the simple solution to the problem discussed would be to ask for encryption more prominent, with a tiny bit of background for the user.

Before i forget, there can be multiply passwords for a luks key, so there is no need to wipe a disk, just have a good OSK with all installed and or system selected languages at hand.


best regards,
Marius