Suggestion: GUI frontend(s) for ecryptfs-utils

Alrighty then, I'll bite :)

Okay, here is a quick initial version in pygtk. Currently there is no underlying functionality, but who cares about that ;)

Where should I go from here? Will mounting or unmounting require a gksudo (or will the UI itself be run with gksudo), and what should the autorun option do, code-wise?

Based on Dustin's comments it appears that checking the automount option should simply create ~/.ecryptfs/auto-mount whilst unchecking it should remove that file. The initial state of the checkbox should be reflect the existence, or otherwise, of that file.

I notice that Dustin also mentions an auto-unmount option. This would presumably be useful if the user wants a process to be able to access the decrypted files after logout, via a cron job or similar. I think if we're in the realms of cron jobs then the user can be considered advanced enough to create their own file, so I would suggest that the auto-unmount option be left out of this application.

I think we also need to consider the terminology used to refer to the ~/Private directory and the act of (un)mounting it. I would suggest text something like this (with reference to the lines on the screenshot):

"Your Private directory is currently encrypted" (when the directory is unmounted, preceded by an icon)
"Your Private directory is currently unencrypted" (when the directory is mounted, preceded by an icon)

"Decrypt your Private directory" (on the button when the directory is unmounted)
"Encrypt your Private directory" (on the button when the directory is mounted)

"Automatically decrypt your Private directory at login" (by the checkbox)

Thanks for the feedback Mark, I agree that the wording can be improved, and like your suggestions. I shall await Dustin's feedback.

For now, here is the initial version of the script. I don't have an Intrepid box running but theoretically the mounting and unmounting *should* work, so give it a try if you can. Just run ecryptfs-ui.py with Python (or if it is executable it will run by itself).

Caveats:
 - It currently can't detect the mount state, so it assumes it is mounted when run. Change this on line 89 if yours isn't mounted, or just mount it before running. Can anyone give me a Python line[s] that will detect this?
 - The automount checkbox currently does nothing (but it sounds easy to implement, from Mark's comment).

Feedback appreciated (and necessary since I can't test myself :)

Okay, here's version 0.2, with functional toggling of the auto-mount option. Note that it still has the second caveat of the first version, so someone feel free to implement getMounted at line 70 :)

I took out the "business logic" or whatever you might call it from the GUI and made an EcryptController class to perform all the implementation details, which cleans up the code I think. Also someone else could import this and use it if so desired.

I also changed the language a bit, with a few differences from Mark's comments. First, the icons are still after the text (you said preceded but I assume you meant proceeded, or didn't you?) I also consistently used "Unencrypt" instead of "Decrypt" because I think that is more understandable for a novice user. Thoughts? Comments? Does it work? ;)

I have an Intrepid installation on a virtual machine at work, but I'm off until next week so won't get a chance to try the app until at least then.

I did mean "preceded": with the text change you end up with a complete sentence, so putting the icon in the middle of the string per the original screenshot seemed a little out of place. Whether it's before or after makes little difference though.

Unfortunately I don't speak Python, so can't help with the code directly, however if nobody's provided any more information by the time I get round to testing this next week I'll have a dig and see if the mount state is exposed anywhere obvious (i.e. /proc/mounts).

Personally I still favour "decrypt" - not least because it's a real word, whereas "unencrypt" isn't (at least as far as dictionary.com and wiktionary.org is concerned).

A quick check of the help browser in my Hardy installation shows "decrypt" used three times (in the "Passwords and Encryption Keys" manual, the "Evolution" manual and the "Archive Manager" manual), whereas "unencrypt" only merits a single mention (also in the "Evolution" manual). From this completely unscientific survey it would seem that the existing documentation in this area favours "decrypt", but it's hardly a landslide victory.

If i dont need and want the ~/Private thing, because i allready set up encryption for entire /home/. Will there be something to turn the feature on/off per user/per system?

On Thu, Aug 14, 2008 at 6:09 PM, shaggy <email address hidden> wrote:
> If i dont need and want the ~/Private thing, because i allready set up
> encryption for entire /home/. Will there be something to turn the
> feature on/off per user/per system?

Quite simply, don't run the 'ecryptfs-setup-private' utility.

:-Dustin

Hi Dustin! I am going to install Intrepid-A4 and wanted to ping you to make sure the instructions I should use to test this are the ones under "Testing" from the Wiki page. I noticed it says it is up to date as of 8/4, and wanted to make sure it was still up to date.

By the way, is this GUI something you want to make into Intrepid and if so, what is the process? Does it need to be its own package? How do we handle translations? I can make an Ecryptfs-GUI project on Launchpad if you think that is appropriate, and figure out how to package and PPA it and then get it into Intrepid, if you find that the best workflow.

I am happy to take this as seriously or not seriously as you find appropriate :) However I do think if this feature makes it into Intrepid, a GUI is pretty important.

And shaggy, I think this feature is still useful for users with encrypted ~/. That is because I assume in general you have to have your Home decrypted pretty much always when logged in for things to work properly. However with ~/Private, this is not typically going to be the case. As such it will allow you to have encrypted data while logged in, with on-demand decryption, if you desire. With an encrypted Home even your most private data is still vulnerable if you are logged in, but keeping your private files in ~/Private and unmounting when you don't need it would keep those safe. Sure, when logged off, ~/Private is "double encrypted" but this shouldn't really matter and is transparent to the logged in user.

The only downside I would see here is if you plug your drive into another computer to access it, you have to decrypt your Home using whatever utility you require, and then use ecryptfs to get at your ~/Private. However for some this added level of security for ~/Private may be seen again as a feature.

Although, this probably belongs on the wiki and not this bug report for a GUI :)

On Thu, Aug 14, 2008 at 10:29 AM, Mike Rooney <email address hidden> wrote:
> Where should I go from here? Will mounting or unmounting require a
> gksudo (or will the UI itself be run with gksudo), and what should the
> autorun option do, code-wise?

No gksudo should be required.

mount.ecryptfs_private and umount.ecryptfs_private are both setuid binaries.

:-dustin

On Thu, Aug 14, 2008 at 11:47 AM, Mark Crutch <email address hidden> wrote:
> Based on Dustin's comments it appears that checking the automount option
> should simply create ~/.ecryptfs/auto-mount whilst unchecking it should
> remove that file. The initial state of the checkbox should be reflect
> the existence, or otherwise, of that file.

Correct. The files are:

~/.ecryptfs/auto-mount
~/.ecryptfs/auto-umount

Note that it is "umount" rather than "unmount". This is to match the
mount/umount system commands.

> I notice that Dustin also mentions an auto-unmount option. This would
> presumably be useful if the user wants a process to be able to access
> the decrypted files after logout, via a cron job or similar. I think if
> we're in the realms of cron jobs then the user can be considered
> advanced enough to create their own file, so I would suggest that the
> auto-unmount option be left out of this application.

I disagree with this. Please make both checkboxes available.

I can think of a handful of cases where users would like this
mounting/umounting to occur, or not occur independently.

The underlying functionality is present in pam_ecryptfs, and I see no
reason to hide it.

--
:-Dustin

On Thu, Aug 14, 2008 at 12:12 PM, Mike Rooney <email address hidden> wrote:
> - It currently can't detect the mount state, so it assumes it is mounted when run. Change this on line 89 if yours isn't mounted, or just mount it before running. Can anyone give me a Python line[s] that will detect this?

Hi Mike-

I can point you to the source code of ecryptfs-setup-private, where I
have a check (in shell code) to see if it's already mounted. It looks
something like this:
...
# Check for active mounts
MOUNTPOINT="$HOME/$PRIVATE_DIR"
CRYPTDIR="$HOME/.$PRIVATE_DIR"
grep -qs "$MOUNTPOINT " /proc/mounts && error "[$MOUNTPOINT] is already mounted"
grep -qs "$CRYPTDIR " /proc/mounts && error "[$CRYPTDIR] is already mounted"
...

Basically, dig through /proc/mounts looking for the private directory.

:-Dustin

On Thu, Aug 14, 2008 at 4:30 PM, Mark Crutch <email address hidden> wrote:
> Personally I still favour "decrypt" - not least because it's a real
> word, whereas "unencrypt" isn't (at least as far as dictionary.com and
> wiktionary.org is concerned).

I tend to agree... "decrypt" sounds better than "unencrypt".

From a technical standpoint, what you're doing is actually "Mounting
the Encrypted Directory", which makes it readable, and "Unmounting the
Encrypted Directory" makes it unreadable again.

Those terms would be more true to form, of what's actually being done.

But perhaps too technical for the target audience? Thoughts?

:-Dustin

On Fri, Aug 15, 2008 at 9:13 AM, Mike Rooney <email address hidden> wrote:
> Hi Dustin! I am going to install Intrepid-A4 and wanted to ping you to
> make sure the instructions I should use to test this are the ones under
> "Testing" from the Wiki page. I noticed it says it is up to date as of
> 8/4, and wanted to make sure it was still up to date.

Yes, those are current. I just installed a new KVM and used those instructions.

I will note that the "auth-client-config" command will hopefully be
going away soon. Steve Langasek is working on a PAM configuration
framework that I should be able to require and call in the
ecryptfs-utils package itself to setup the pam_ecryptfs module
appropriately.

I will keep those instructions up-to-date.

> By the way, is this GUI something you want to make into Intrepid and if
> so, what is the process?

Personally, I would very much like to see a GUI in Intrepid. However,
I doubt it would make it into Main. It would probably need to go into
Universe for Intrepid, but, of course, I'm not the final arbiter of
any of this ;-)

> Does it need to be its own package?

Yes. The ecryptfs-utils package is currently technically a "server"
package, so we couldn't/shouldn't start requiring gtk, etc.

I'm going to ping the upstream ecryptfs-utils maintainer and ask what
his opinion on the proper "home" for an ecryptfs-util-gui project
would be.

> I can make an Ecryptfs-GUI project on Launchpad if

Agreed. I suggest you call it "ecryptfs-gui". We'll need the
packaging, and such done too. At which point, we can provide binary
installables in a PPA.

Next, we'll propose it as a new package in REVU,
http://revu.ubuntuwire.com. It'll go through a vetting process, and
we'll need people advocating its inclusion into Universe.

> How do we handle translations?

I have no idea :-)

> I am happy to take this as seriously or not seriously as you find
> appropriate :) However I do think if this feature makes it into
> Intrepid, a GUI is pretty important.

Agreed. Hopefully, we can get this into Universe.

:-Dustin

On Fri, Aug 15, 2008 at 11:16 AM, Dustin Kirkland
<email address hidden> wrote:
>> I can make an Ecryptfs-GUI project on Launchpad if
>
> Agreed. I suggest you call it "ecryptfs-gui". We'll need the
> packaging, and such done too. At which point, we can provide binary
> installables in a PPA.

Actually, strike this....

I have talked to the upstream ecryptfs-utils maintainers and they are
quite willing an interested to integrate GUI into the main
ecryptfs-utils project.

This code is currently housed at:
 * http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=summary

It will take some packaging magic on our end to get ecryptfs-utils to
spit out a separate ecryptfs-gui package, but that shouldn't be too
hard.

:-Dustin

> Those terms would be more true to form, of what's actually being done.
>
> But perhaps too technical for the target audience? Thoughts?

I agree about the use of "mounting" and "unmounting" being too technical for this application. With a layperson it might also lead to confusion with the need to unmount external drives before they're detached - we don't want to give the impression that the encrypted data are somehow outside of the user's home directory. Although not technically correct, I think the use of "encrypt" and "decrypt" convey the right sense of what is being done, from the end-user's perspective.

If we're having checkboxes for both auto-mount _and_ auto-unmount, I wonder whether they might be better moved off of the main UI and into an options screen. The button to (un)mount ~/Private could potentially be used very frequently, whereas it is likely that these options will be touched only very occasionally. As such it might be worth moving them out of the primary UI, partly to avoid accidental clicks on them, and partly to simplify the main screen.

Of course this then raises the question of how to open such an options screen - adding another button to the primary UI kind of defeats the purpose. I would suggest a menu bar, with nothing more than File>Quit and Edit>Preferences on it. Thoughts?

> I agree about the use of "mounting" and "unmounting" being too technical
> for this application.

Yes, I must admit I too feel this way. Though we don't want to be
inaccurate in a way that confuses more knowledgable users, although I
am not convinced the current terminology of encrypt/decrypt does, so
we may be okay.

> Of course this then raises the question of how to open such an options
> screen - adding another button to the primary UI kind of defeats the
> purpose. I would suggest a menu bar, with nothing more than File>Quit
> and Edit>Preferences on it. Thoughts?

Probably just make it tabbed and have a second tab for the
checkboxes/persistent options.

> Actually, strike this....
>
> I have talked to the upstream ecryptfs-utils maintainers and they are
> quite willing an interested to integrate GUI into the main
> ecryptfs-utils project.

Hmm, well that is good in ways, but doesn't that change the scope of
this then? My idea was to have a simple GUI tailored to Intrepid's
implementation, that is, an encrypted ~/Private. If upstream wants a
GUI, I assume it would be completely different. What would a GUI look
like that is useful to ecryptfs-utils generically but also good for
Intrepid users? Maybe I am just confused... :)

Okay, I tested it on Intrepid and it works! By the way, the small project now lives at https://launchpad.net/ecryptfs-gui.

Dustin, any feedback on my previous comment? I am not sure exactly where to go from here.

On Tue, Aug 19, 2008 at 4:08 PM, Mike Rooney <email address hidden> wrote:
> Okay, I tested it on Intrepid and it works! By the way, the small
> project now lives at https://launchpad.net/ecryptfs-gui.
>
> Dustin, any feedback on my previous comment? I am not sure exactly where
> to go from here.

I think your LP project is okay for now, until we get to a point when
we're ready to push it upstream. Obviously, we should have this
somewhere under version control while you're developing it ;-)

I, too tried it, and it worked okay for me.

Is there any chance you could take a look at putting a frontend on
ecryptfs-setup-private? The manpage and the usage statements should
document the necessary/optional inputs as well.

I'd love to add an entry to System->Preferences->Encrypted Private
Directory where users could go to initially set this up, and then
later configure it.

:-Dustin

(icons from Epiphany.)

Thanks Tobias. Did you actually code that or is it just a graphical mockup? If there is code a patch would be appreciated. Thanks!

Well, the patch is so trivial, that I found it not worth posting.

What I'm really wondering is, where and how will this UI be presented? Did you think this through, yet?

My initial impression is that this will sidestep the established desktop mechanisms. Shouldn't this be intregrated with upstream? What about PolicyKit to avoid suid root? What about making this button a banner at the top of the nautilus window, similar to what you get in the Trash Bin view, or on memory cards with photos? Shouldn't the little eject icon in the Nautilus sidepane work for an unmount?

The icons are /usr/share/epiphany-browser/icons/hicolor/48x48/status/lock-{in,}secure.png

I certainly prefer the larger icons, but I question whether or not the big icon should be on the button. An icon on a button should usually indicate what the button will do, not what the current state is.

I would suggest having the icon grouped with the string "Your Private folder is currently...", and have the button to (un)lock as a separate entity with some space separating them. Of course this doesn't preclude the big icon _also_ acting as a button to (un)lock, maximising the clickable area for those that know about it, but it makes it clearer that the icon is showing the current state, rather than the projected result of clicking the button.

My original suggestion for a UI was to create a Gnome panel applet for (un)locking the Private folder, and ideally for there to be integration into Nautilus and the Open/Save dialogue. Unfortunately I'm not able to code any of this myself, and Mike was good enough to step up with the current application. It may not be ideal, but until someone writes something more appropriate it's better than no UI at all.

As for Nautilus integration, I raised this on the wiki and was informed that the current implementation of encrypted Private directories is being handled by the Server Team, who have no remit for anything other than command-line implementations. I therefore filed an issue in Launchpad specifically relating to Nautilus integration: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/259799

The position on that issue is that the Desktop Team has no resources available to work on this, so it should be filed upstream. I haven't yet done this, so feel free to open an upstream bug if you wish.

I think the vault should be locked/unlocked in situ, i.e., right inside the folder view. This may be possible in Nautilus with a ribbon on top similar to the Trash view.

I’m a fan of this:
http://www.iclarified.com/images/tutorials/177/698/698.png

I'll attach a mockup of how I feel it would work well. This is of course not possible in open/save dialogs.

Thanks for the merge Dustin. Are the necessary changes in for the packaging to actually ship the API correctly? If so I can merge that into my nautilus branch and propose a merge for that which should help provide a basic API.

Sorry, that should be "help provide a basic GUI".

Another release and I still haven't found any time to work on this.

CC'ing Martin Pitt, desktop team lead. Martin, too late for Karmic, but do you think you or someone on your team might be able to throw a little bit of effort into merging the UI work that Michael has done, and ensure that we have sufficient GUI integration for eCryptfs functionality?

:-Dustin

If you need any help, let me know. The nautilus integration branch is
at lp:~mrooney/ecryptfs/nautilus-integration which depends on the API
branch. Dustin, I saw you merged that branch but is the API actually
being installed anywhere?

I put desktop-karmic-ecryptfs-desktop-ui on my list of desktop things to have for Lucid.

Awesome! Thanks, Martin.

:-Dustin

If I am at UDS-L I could probably pretty easily work with either of you two to integrate the branches and add any desired features; if you think that would be useful, put in a good word for my sponsorship ;)

Looking at the attachments in this bug report, I noticed that an attachment was not flagged as a patch. A patch contains changes to an Ubuntu package that will resolve a bug and this attachment is one! Subsequently, I've checked the patch flag for it. In the future when submitting patches please use the patch checkbox as there are some Launchpad searches that use this feature. You can learn more about the patch workflow at https://wiki.ubuntu.com/Bugs/Patches.