Dear Fedora Developers

I want to be able to click a tickybox in anaconda/live-cd when setting up my home partition:

[X] Encrypt home directory

And then for everything to just unlock when I enter my login password at GDM.  Why am I drowning in concepts like dm-script, pam, cryptsetup and all that other geeky stuff for something so trivial?  If you do this I'll be happier than a dog with two thingies. 

Published by

hughsie

Richard has over 10 years of experience developing open source software.  He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards.  Richard has three main areas of interest on the free desktop, color management, package management, and power management. 
Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering.  He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment.  Richard's outside interests include taking photos and eating good food. 
View all posts by hughsie

One thought on “Dear Fedora Developers”

We're working on some bits for easier file system (well, really block device) encryption for Fedora 9 that will basically boil down to [X] Encrypt and protect data that then prompts you to unlock at boot.  First anaconda bits landed about a week ago, but there's still quite a bit more work to do.  The problem with the “encrypt my home directory” case is that all of the encryption solutions are block device based.  And a separate block device per user home directory just doesn't scale.  Growing and shrinking filesystems online sucks (ie, you can't shrink) and you can't know a priori how much space each user is going to need.  So blah, losing.  eCryptFS is somewhat promising as an overlay filesystem, but alas, not nearly ready and progress is slow on things like separate encryption keys per fs subtree and allowing things like a ~/Public which _isn't_ encrypted (so that it can be access by apache which won't have access to your keyring and thus wouldn't be able to decrypt it)