Comment 19 for bug 1773457

Revision history for this message
Milan Niznansky (online-minosi-deactivatedaccount) wrote :

@Phillip

I believe that in the heat of the argument the key point was lost.

In the enterprise world, the "desktop" method of "lets assume we can wipe all user data" and "lets assume this is a single-disk use case" simply do not add up.

For me, the current model is simply unusable for 2 fundamental reasons:
A) As a corporate policy /precedes GDPR, but I presume it is not unique/ the only partition except from mandatory encryption is the EFI partition. This is not up for discussion. There is NO WAY you will even be able to win this argument with the InfoSec Crowd. Because they are right. You need to assume *not only* scenarios of external attacker but also the user himself mis-using the /boot partition to exchange confidential data. And please do not go with the "then you are already compromised so you lost anyway" argument. The point is is defense-in-depth. With trusted boot you can actually ignore the EFI-the system will refuse to boot if the EFI is messed with. Etc.

B) And this is even more critical, I have a powerfull workstation with several SSDs used as Virtualization host for a bunch of VMs under VMware workstation. I NEED to use custom partitioning to be able to create a custom LUKS volume and pass that volume directly to VMs to do their stuff - while staying fully encrypted on the HW level.

In summary, for "Kid's computer", the current approach is fine. No question there. Bu then, for a Kid's computer, Win10 is fine too so is a Mac ...

What this bug report is about is how to address PROFESSIONAL / ADVANCED use cases seemlessly.
Right now, the solution prepared by Paddy is absolutely fine - and it is even fine if it is NOT included in Uniquity.
But we should get the Grub bug fixed - bar the need for the "RefreshGrub" script, I found Paddy's solution infitintely more practical than being forced to use Red Hat (which supports a custom configuration just fine) or a Mac for that matter.

I am marking this against Grub too - as maybe first step is to fix the Grub bug and once that is done, consider extenting this to Ubiquity for the next LTS cycle.