> Log: > https://meetbot.fedoraproject.org/fedora-meeting-2/2018-12-03/workstation.2018-12-03-14.05.log.html > * Default disk partitioning layout for Workstation (mcatanzaro, > 14:11:08) > * ACTION: otaylor form a subgroup to look at LUKS issue -- WG is not > taking any specific actions until subgroup recommends something > (stickster, 14:41:48) > * LVM and /home partioning issues will depend on subgroup report > recommendation for LUKS (stickster, 14:44:00) - If only /home is encrypted, it requires a separate filesystem/volume for /home. - The main purpose of dropping LVM is to address the small root running out of space with flatpak installations in https://pagure.io/fedora-workstation/issue/54 - If separate home, then issue 54 needs a different solution. e.g. increase root size above 50G. However, some people will have workflows where they run out of space on root or home, no matter what we pick, just due to mismatching expectations. The problem will be more common for the dual boot and small physical device cases (many laptops have 128G SSD drives in their base configuration); and in particular when both uses cases happen simultaneously. Alternatives: a. Combined root and home, encrypt that volume (everything). b. Combined root and home, do not encrypt. For what it's worth, Windows 10 and macOS 10.13 do not encrypt anything by default. c. LVM thin provisioning doesn't really solve anything out of the box, because right now Anaconda won't permit over provisioning, therefore we still can run into the problem in issue 54. Only users with esoteric knowledge will know or be able to explain how to overprovision root and/or home volumes, to avoid or fix the problem in issue 54. d. ext4 encryption by default in only /home Regarding a.) with LUKS/LUKS2. The convention is to have a single device encryption passphrase shared among users, and this passphrase is different than the user login passphrase. I think this is a half assed UI/UX, having to enter two passphrases. It's archaic, and not worth any additional effort. People who manually tick the box in Anacond to encrypt, pretty much know what they're signing up for, which is this cockamamie UI/UX that doesn't exist on any other platform. A better approach requires: - Anaconda needs to know how to use a single passphrase for both LUKS and user login and how to associate user with LUKS key slot. - Likely a format change for /etc/passwd or some other file, to associate user login and LUKS key slot; while a passphrase could be cached and LUKS cryptsetup will use any offered without reference to a user, we need to know which slot to wipe when changing passphrases, therefore it has to be tracked. - GDM needs to know how to use single passphrases to both login and unlock volume. - If full disk encryption, rather than home only encryption, plymouth or GDM login or something like it needs to become available in early boot, i.e. part of the initramfs. This should present a user login, capture credential one time, and both unlock the encrypted volume and then login the user in one shot. Regarding d.) both f2fs and ext4 support file level encryption via fscrypt, and is used by newer Android devices by default. This can be done on a directory or file specific basis. And the file encryption passprase can be tied to the user login passprase. Anaconda and GDM work is implied to support anything related to fscrypt. Both a.) and d.) have the liability that the passphrase encoding method needs to somehow be made consistent and reliable no matter what language or keyboard layout is chosen when setting or changing that phrase; because as mentioned, nuking people's data by effectively locking their data behind an unknown or unknowable passphrase encoding, is bad. Worst case scenario is to at least inform the user that the selected language and/or keyboard can't be used to unlock the encrypted data; and also inform the user which language and/or keyboard they need to switch to, to make it possible, and to give them the UI necessary to do that. >>14:31:51 <otaylor> ryanlerch: I think it's definitely possible (finicky, but sometimes you have to do finicky things...) to determine whether a password is possible to type at the bootloader password prompt Literally GRUB2 asking for a passphrase, implies /boot is encrypted. I'm not sure that's supportable. Anaconda has various limitations where it will require a separate boot volume. What are the advantages to encrypting boot? disadvantages: - there is presently no GRUB2 GUI, it's really clunky in appearance - it implies the user will have to do dual passphrase entry, once at the bootloader and again when logging in, this is also clunky Maybe a ~5 year view and plan are needed to better understand the problems, solutions, and what resources are available. -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
