Ubuntu Single Sign On Client

Bug #745540
Comment #57

Comment 57 for bug 745540

Revision history for this message

Danny Sauer (ubuntu-dannysauer) wrote on 2011-10-16:

#57

Later on, I copied my existing login.keyring to a file named "default,keyring". That caused the ubuntuOne application to prompt me to create a new keyring named default. If I typed a password in, each time, I would be told that a user pressed cancel on the application. But if I allowed the keyring daemon to "create a new keyring named default", and just hit ok with no password (and clicked "store passwords insecurely"), It worked fine.

I'm now connected to UbuntuOne on the broken machine, but in the passwords and keys app, I have an empty keyring named default, my old keyring named login, and a new one named default_1 which contains my UbuntuOne password.

Oddly, the file command shows that default_1.keyring is just ASCII text, while the login.keyring is recognized as
login.keyring: GNOME keyring, major version 0, minor version 0, crypto type 0 (AEL), hash type 0 (MD5), name "login", last modified Mon Dec 14 08:11:29 2009, created Mon Dec 14 08:11:29 2009, not locked if idle, hash iterations 1653, salt 3211078258452735141, 6 item(s)

So, I went in and changed the password on default_1 - the new keyring created when I started up UbuntuOne. I could still run u1sdtool -q / -c, and it would reconnect fine. Then I shut down UbuntuOne, deleted the UbuntuOne password from default_1, and ran u1sdtool -c. It opened up the login prompt as it should, and went ahead and logged in. It created a new entry (ID #2, even though #1 was deleted) in the default_1 keyring.

So, this seems to be a collection of keyring failures:
1) creating a new-format keyring with a password always returns failure (probably because it defaults to not being unlocked?)
2) whatever call UbuntuOne is using, it can't seem to add entries to the old format keyring
2a) the password and keys app can happily add and remove passwords from both the new and old-format keyrings

The full workaround for UbuntuOne appears to be
  1) move old keyring file out of the way
  2) allow UbuntuOne to create a new keyring with an empty password
  3) move the old keyrinng back into the keyrings directory
  4) start up Passwords and Keys and set an actual password on the new keyring

Later on, I copied my existing login.keyring to a file named "default,keyring".  That caused the ubuntuOne application to prompt me to create a new keyring named default.  If I typed a password in, each time, I would be told that a user pressed cancel on the application.  But if I allowed the keyring daemon to "create a new keyring named default", and just hit ok with no password (and clicked "store passwords insecurely"), It worked fine.

Oddly, the file command shows that default_1.keyring is just ASCII text, while the login.keyring is recognized as
login.keyring:        GNOME keyring, major version 0, minor version 0, crypto type 0 (AEL), hash type 0 (MD5), name "login", last modified Mon Dec 14 08:11:29 2009, created Mon Dec 14 08:11:29 2009, not locked if idle, hash iterations 1653, salt 3211078258452735141, 6 item(s)

So, I went in and changed the password on default_1 - the new keyring created when I started up UbuntuOne.  I could still run u1sdtool -q / -c, and it would reconnect fine.  Then I shut down UbuntuOne, deleted the UbuntuOne password from default_1, and ran u1sdtool -c.  It opened up the login prompt as it should, and went ahead and logged in.  It created a new entry (ID #2, even though #1 was deleted) in the default_1 keyring.

So, this seems to be a collection of keyring failures:
 1) creating a new-format keyring with a password always returns failure (probably because it defaults to not being unlocked?)
 2) whatever call UbuntuOne is using, it can't seem to add entries to the old format keyring
  2a) the password and keys app can happily add and remove passwords from both the new and old-format keyrings