ecryptfs team mailing list archive

[Dustin Kirkland <dustin.kirkland@xxxxxxxxx>]

As I said above, this should be a clear case for an SRU for Intrepid.

I do not believe this is a release critical bug, because it only affects:
 - users of the alternate/server iso
 - who have a "%", or a "-" in their chosen passphrase
 - and have elected to setup an encrypted private directory in the installer.

When this occurs, the ecryptfs-setup-private step fails, however, the
installation proceeds normally.  Upon reboot, the user will find that
their encrypted ~/Private directory is not mounted, and with permission
0500 (r-x------), and thus no data should be written there.

To remedy the problem after the first boot, the user will need to
upgrade ecryptfs-utils (to the version we will SRU), and then run
"ecryptfs-setup-private --force" to reconfigure their encrypted
~/Private directory correctly.

:-Dustin

-- 
ecryptfs-setup-private fails if passphrase contains character "%"
https://bugs.launchpad.net/bugs/290445
You received this bug notification because you are a member of eCryptfs,
which is subscribed to ecryptfs-utils in ubuntu.

Status in eCryptfs - Enterprise Cryptographic Filesystem: Fix Committed
Status in Ubuntu Release Notes: New
Status in “ecryptfs-utils” source package in Ubuntu: In Progress

Bug description:
Binary package hint: ecryptfs-utils

Ecrypt-setup-private asks for user login passphrase, but it seems to fail if there are certain special characters in passphrase (for me that would be %).

I'm running Ubuntu 8.10
ecryptfs-utils version 53-1ubuntu11