My working assumption is that g-i-s and Users panel need to grow the
ability to present appropriate interface for per user encryption;
maybe that could be as simple as an "encrypt" checkbox at user
creation time, ticked by default.
1. How to handle Anaconda vs GNOME encryption features?
a. It's not apparent that the two offerings differ, how they differ,
that they can be combined, that combining them has consequences.
b. In the Installation Destination spoke, "Encrypt my data" is visible
and unchecked by default. It could be construed as user home only
encryption. It is, however, full disk encryption (minus /boot).
c. If user chooses this option in the installer, now what? Do not
enable or even present the GNOME encryption features? Or double
d. Alternatively, does it get renamed to better indicate it's full
disk encryption? Or remove it entirely?
2. Consequences of an fscrypt/ext4 only solution
a. Users choosing anything other than ext4 not only don't get user
home encrypted by default, they can't opt into what we're initially
b. In some sense it diminishes the message that privacy of user data
is important, because it comes with a "only if you pick ext4" catch.
c. How would the user be informed of a & b (goes back to #1).
3. Upsides of fscrypt/ext4 only solution
a. Faster delivery than systemd-homed? (Is this certain?)
4. What about /home only encryption?
a. Wrap a single LUKS passphrase stored for each user login? Any valid
user reveals that passphrase, and is automatically used to unlock
/home; g-i-s could one-time acquire the LUKS passphrase used during
installation from the (first/admin) user
b. Use each user's login passphrase as a LUKS passphrase, stored in a
LUKS keyslot? (Might aid chance of recovery in case all login files
c. Requires Anaconda changes. Retask "encrypt my data" to mean /home
encryption? How to indicate full disk encryption? Present both
5. What about always using a /dev/urandom derived key at boot time for swap?