Description of problem:

For some reason I am unable to properly use passwords with LuKs and the automount stuff in Gnome. These passwords contain the the characters '12' in them in that order. 

That is.. any passwords will work fine, except ones that have 12 in them. Then I get dbus errors and whatnot popping up on my screen.

I have no idea what is going on, but it seems that somewhere along the line there is a program that is not properly sanitizing input and thinks that '12' is significant in some form.

I get two errors that pop up on my gnome desktop when I plug in a LUKS encrypted USB device and successfully enter the correct password:

First I get:

"Cannot mount Volume"
Error org.freedesktop.Hal.Device.UnknownError.

Then when I press the triangle for the 'Details' I get:
"A unknown error has occured"


The second error dialog doesn't pop-up immediately, but after a second or two:

Unable to mount 2.0 GB Encrypted Data
DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.


I think the second error is not related directly to the first. I think it's just to inform you that the communication with hald has timed out and the actual error is very misleading.  It's the same dialog that will pop up if you do not enter your password in a timely manner.

The odd thing is that it DOES mount the volume successfully. Not every single time, but most of the time. It seems to perform very badly with SD cards, but with USB Flash drives it seems better behaved.

So it seems to me that somewere between HAL, Dbus, or Gvfs stuff there is something very wrong going on. If HAL or Dbus isn't sanatizing input correctly then it may even be a security issue in a multiuser environment. 

But I have no way of knowning which component is goofing up. 



Version-Release number of selected component (if applicable):
gvfs-1.0.3-4.fc10.i386


How reproducible:

Plug in a USB drive. Run the various cryptsetup commands to create a LUKS-encrypted volume. Format it ext3. Add a password that contains '12' in it. 

Plug in the device and use the '12' password and then witness the odd errors.

Steps to Reproduce:

1. Plug in device. (assuming it's a USB drive that shows up as /dev/sdb with one partition)
2. run cryptsetup commands to setup luks volume: 

(use 'taco' as the main passphrase)
[root@sylvester ~]# cryptsetup luksFormat /dev/sdb1

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:  
Verify passphrase: 
Command successful.


(using 'taco12' as the second key)
[root@sylvester ~]# cryptsetup luksAddKey /dev/sdb1
Enter any LUKS passphrase: 
key slot 0 unlocked.
Enter new passphrase for key slot: 
Verify passphrase: 
Command successful.


(using 'taco12' as the key to confirm it's working)
[root@sylvester ~]# cryptsetup luksOpen /dev/sdb1 poo
Enter LUKS passphrase for /dev/sdb1: 
key slot 1 unlocked.
Command successful.

(format volume)
[root@sylvester ~]# mkfs.ext3 /dev/mapper/poo > /dev/null
mke2fs 1.41.3 (12-Oct-2008)
[root@sylvester ~]# echo $?
0


3. Remove device and plug it back in while running Gnome desktop. 

4. When the 'Unlock Encrypted Data' dialog pops up use the 'taco' passphrase and see that it properly mounts and displays contents of the encrypted volume with no errors.

5. right click the icon on your nautilus desktop representing the encrypted volume and select 'Unmount Volume'

6. Remove the device and plug it back in again. This time use the 'taco12' passphrase.

7. Witness the 'cannot mount volume' errors. 

  
Actual results:

The device gets mounted (sometimes) and you get odd and misleading errors on your desktop. Sometimes you can umount it. Other times you need to become root to umount it.


Expected results:

the icon appears on my desktop and nautilus displays contents of encrypted volume. 

Additional info: