This is a rather late first update on my project, unfortunately it’s been a bit of a rough start.
First, if you don’t know what it is, the project is to integrate folder encryption into GNOME in a seamless manner. The goal is to provide encryption without interfering with the user experience. This will be achieved by having a folder decrypt on-the-fly when it is opened, using the keyring to handle passwords. The result is that you should be able to treat an encrypted folder exactly like a regular folder.
In order to ensure this works from any GNOME application (file manager, open/save file chooser etc.) it was decided that this should be integrated into gvfs. I have spent most of the time till now digging through gvfs and attempting to work out how to integrate this into gvfs. Unfortunately, we’ve been unable to work out how to do so. We’ve decided to revisit this at GUADEC and there we will work out a way to complete the core of the project.
Until then, I have started working on some code in Nautilus to create the interface for creating a new encrypted folder. It presents a convenient “Encrypt folder” in the context menu, when selecting a folder and encfs (the program that handles encryption) is installed. I’m just finishing this off by moving the contents of the folder to a tmp directory before it’s encrypted, and moving it back after encryption is complete. This part may be moved into the core code later.
When the core project is completed, I’ll also need to check for already encrypted folders before displaying the option, and have it actually perform the encryption, which should be easy to drop into the existing code.
Before GUADEC, I will also put together some code to handle the libsecret handling, which can then be dropped into the core code after GUADEC.
Finally, if you would like to play with this, you can get the old nautilus plugin prototype here.
Watching with interest! 🙂
I’ve been waiting a long time for that feature – we could finally discard Cryptkeeper. Out of curiosity, is there a reason for using encfs rather than ecryptfs?
es, this is just along the lines of what I’ve been thinking about.
My original thought is support for drag-and-drop encryption to an folder or partition, where you just grag any file (or folder) and drop it into the encrypted file or partition.
Encryption/decryption will be done on the fly, with/without user input.
I’m watching this closely.
I think a simpler strategy to encrypt folders is to mount the encrypted folder to a temp folder move the content and then remove the remains ( hopefully permanently ) and mount it to the existing folder. Nothing happens if thing fail and you don’t have unnecessary moving of possible large file and possible some security problems.
Keep up the good work 😉
That’s actually an excellent idea. Thanks for the suggestion.
I’d prefer ecryptfs over encfs. Ecryptfs is in the kernel, encfs is a userspace filesystem. This means that ecryptfs is available on almost all systems; and that ecryptfs is more efficient than encfs.
As I understand it, ecryptfs requires root to set up. As something that is designed for users to use trivially, it should not require root access everytime you want to encrypt another folder. If I am mistaken on this requirement, then I’ll be happy to have another look at it.
I dont think dhat you need root. I never used ecryptfs but the ecryptfs-utils seems to run in userspace. Take a look herehttps://wiki.archlinux.org/index.php/ECryptfs theonly thing i see is that the kernal module have to bee loaded. But in other case you also have to install encfs. That make no difference for me but ecryptfs seems to bee more powerfull
I forgot to reply earlier, but you can just provide a service over the system dbus or install a setuid handler like ecryptfs-tools does for the user’s Private directory to be able to mount an ecryptfs directory.