What are the thoughts on new tpm backed disk encryption and implementation of systemd- homed in gnome with tech fund.
From the :
What are We Funding
- Encrypt User Home Directories Individually: Implementation of systemd-homed backend to encrypt user home directories, bolstering security measures.
- Increase Range and Quality of Hardware Support: Optimization of GNOME desktop for diverse input methods and display devices, along with performance improvements.
- Modernize Platform Infrastructure: Refinement of desktop notifications API and modernization of GTK CSS engine, among other platform updates.
- Improve Quality Assurance and Development Tooling: Enhancement of GNOME OS and related tooling to facilitate continuous integration testing and streamline development processes.
- Improve State and Compatibility of Accessibility: Overhaul of accessibility stack to ensure compatibility with modern technologies such as Wayland and Flatpak, along with advocacy for accessibility integration in software development practices.
- Design a New Accessibility Stack for Linux Desktop: Creation of new accessibility protocols to replace outdated components, promoting compatibility with sandboxed applications and modern security standards.
- Maintenance and Modernization of Security Components: Upgrading and maintenance of security-related components like Seahorse, Keyring, and libsecret, incorporating essential security features and enhancements.
- Secure APIs for Wayland/Flatpak: Development of secure APIs for accessing resources and user data in Wayland and sandboxed applications, ensuring robust security measures for the Linux desktop environment.
From Phoronix “https://www.phoronix.com/news/GNOME-Better-Homed” :
GNOME developers have also been busy working on features like improving the systemd-homed integration and beginning to work on mock-ups for an OS installer.
This Week In GNOME is out with their latest installment to highlight activity for the week. Some of this week’s milestones include:
-
Thanks to the Sovereign Tech Fund efforts, there is work on getting a FileChooser portal implementation working with the Nautilus file manager.
-
The first iteration of the work to make systemd-homed secure when used in combination with desktop environments is now finished.
-
Systemd-homed “secure locking” is now wired up for GNOME Shell and GDM where the home directory is re-encrypted and the key is evicted fro memory.
-
The first beta release of TypeScript bindings for GNOME.
-
Improved WebDAV interoperability in GNOME online accounts.
As for your other comment :
It’s optional, and has been available on Linux for a long time. So You will need to elaboratre on what you are conveying here 
1 Like
I’ll only use it when it just-works without barely doing anything.
My experience with LUKS, dm-crypt, and SSD trim in the past was too annoying to reproduce, slower even with CPU AES on NVMe, and my actual secret files (like password databases) are already encrypted by their own means. I don’t bother with full-disk encryption and see no appeal to yet.
However I did like that when I installed Windows 11 Insider that it automatically Bitlocker’d the drive in the background without me knowing it up until I was trying to tweak something and it warned me to disable Bitlocker. That’s how full-disk encryption should be if offered as a default in an OS! It should just-happen as a low-priority background task, or automatically be done install-time with the TPM2 link and no visibility of it. Android’s been doing it subtly for years.
If I have to enter a passphrase or anything at boot time, it’s getting reinstalled unencrypted real quick 
You named both implementations of Encryption that are fairly insecure. Both Bilocker and Android versions give you no visibility on the key for the encryption. Which means you have nothing at all.
With Luks it’s done at install time. So it’s not in the way at all. You have ownership of the key.
Big Difference.
With disk encryption I’m more interested in protecting my data from unauthorized users (like someone jacking my phone or laptop at a coffee shop). If I don’t have the key, nobody else does either (besides the main company offering the OS I guess, and if they have to be involved to unlock my device I’m sure I’d have bigger issues going on). Worst-case if I lost the key or the TPM decided to clear itself, I’d just reinstall from backups, along with never trusting that implementation again and going unencrypted.
I like the idea of owning my own key, but I’m not entering a passphrase every boot on a computer in my house that likely isn’t getting stolen. If Luks hooks up to TPM on Linux at install-time, requires nothing to type on boots, and no manual maintenance, I might be fine with it as long as it lets me trim SSDs too (I’m fine with adversaries potentially knowing I have disk encryption or whatever trimmed cells might leak as long as they can’t see the data or get a key from it)
I believe you’ve missed my point. I digress.
I understand both @Espionage724 and @hamrheadcorvette point of view.
On one hand there’s full control of the encryption/recovery key, on the other hand there’s the annoyance of needing to enter the encryption paraphrase at every boot/reboot. And if the system is being used by multiple users, each of them has to know the key.
What are your opinions of macOS’s FileVault implementation? AFAIK the disk is being encrypted with the admin user’s initial password, you have an additional recovery key if you forget your password, user can change its password (and in turn the cryptographic keys) without requiring re-encryption of the entire volume, and each user’s login password unlocks the encrypted disk.
I really think fedora should enable encryption more prominently and also a systemdhomed enabled by default for all users.
1 Like
the TPM encryption is not GUI accessible, so I would not say it is “available” for normal users
I found this ublue script which gives a headstart
I’m not sure where I said that
But since you brought me back here today, I want to add :
With LUKS, you can have numerous keys to unlock a device. ( I believe 12 ) So setting up a Device unlock and a User unlock with a key based system is practical. I have several Devices I monitor for individuals where the Group has Keys, and of course a master password ( which is required ) .
Setting up 1 machine for more users would be the tricky part, but IMO you should reconsider how to administer a machine with more than 12 users who would need to boot the machine. That’s cause for a different solution altogether.
1 Like
Crazy stuff that is hidden there.
Do you know if the Anaconda WebUI has improvements here?
I have not checked it, but recent developments in cryptsetup allow for more use of hardware tooling on SSDs and NVMe’s directly. The newer versions of cryptsetup should have this baked in. Also, the default needs to change. I think I know people want this changing key derivation and iterations is important for some users, especially key holders. Also, making a way for the user through a GUI, to change these “advanced” settings, would be very helpful. Adding or Enrolling FIDO2, YubiKeys should be standard now and included in any advanced GUI features.
1 Like
Amen.
I think it’s a matter of trade-off. I would rather have those 12 recovery keys for disaster recovery, than for daily use (put them in one or more safes and forget about them… until you forget your master password).
But say in a family setup, with multiple family members using the same system, and with the “main” user not wanting to share its password with the rest of the family (that’s mean, I know), the other users booting up the system would have to remember both the user password and some recovery key. That’s not that user friendly.
And no, I am not thinking of families with more than 12 members 
. That happens only in the movies (you know, with Steve Martin & Co).
1 Like
I assume systemd-home is independent of the DE. So would this be available in the KDE edition as well?