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 _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs More help : https://help.launchpad.net/ListHelp

