ubuntuone-preferences crashed with NoSuchKeyringError in __init__()

I have set this bug report to public as the automatic retracer has set this as the "master" bug report & there is no private/ sensitive information in the attached logs/ files.

I didn't doubt that my https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/569566 report was a duplicate of this one... but as this one was not public I couldn't check!

Thanks for the status change.

So, I move my comments on this master report.

My findings are that this behaviour seems identical with other programs using the keyring (such as NetworkManager, although NM do not crash, but instead keeps asking for a keyring creation)

So I suspect the bug is on the keyring access layer (library ?)

I noticed the default keyring file changed from

(Karmic)
/home/$USER/.gnome2/keyrings/login.keyring

to

(Lucid)
/home/$USER/.gnome2/keyrings/par_défaut.keyring

That is on a French system.
"Par défaut" means "Default" in French.
And notice the "é" in the filename

So my guess is:
- the default keyring is created
- when the calling program tries to access it, it doesn't find it, because of a poor coding in respect to the UTF-8 filenames
- then if you try again you get more keyring files like :

/home/$USER/.gnome2/keyrings/par_défaut1.keyring
/home/$USER/.gnome2/keyrings/par_défaut2.keyring
/home/$USER/.gnome2/keyrings/par_défaut3.keyring

(this I have reproduced) and it keep crashing of course.

If my guess is right, possible corrections are:
-1) revert the name of the default keyring to login.keyring
-2) change the name of default keyring, in ALL languages that use non-ASCII characters to a name with only ASCII-7 characters
-3) do a proper coding for UTF-8 filenames (probably in keyring related stuff, non in U1)

Options 1 an 2 do not really correct the bug, they are just workaround so that you don't enter portions of codes where the bug is (probably poor UTF-8 coding). The only "real" correction is certainly 3.

... should U1 crash in such conditions when keyring does not work, that's another philosophical question, but should be stated in the specifications of U1.

For example U1 specifications should read:
- In such conditions when keyring do not work properly: do not use it, and instead prompt for password at the daemon launch

or

- In such conditions when keyring do not work properly: crash

I believe the first alternative is better, as it is a "fallback" and you still have a working U1

So I suggest this report gives:
- Status: minor enhancement for U1 -fallback behaviour when keyring is buggy-
- Critical for Keyring (as it do not work at all on non-plain-ASCII-7 languages)

Why oh why oh why is gnome-keyring not using "login.keyring" for these other langauges?

This is actually occurring in desktopcouch. The ubuntuone-preferences script is just importing the module, which is getting this exception inside the module during import.

not sure it's a gnome-keyring issue, seems rather a buggy client asking for this keyring name, it doesn't happen on a default installation

>> it doesn't happen on a default installation

Do you mean a default *english* installation?

And do gnome-keyring support being called with UTF-8 filenames?

Because of course if it does not (which would be, to my point of view an architectural error) clients should not call with UTF-8 name.

If gnome-keyring is UTF-8 compliant and debugged, it could be, as you suggest, a buggy client that do not fully support UTF-8.

At the moment there seem to be the same problem with Network manager that do also try to use gnome-keyring to store Wifi passwords.

We are tracking that on this *french* post : http://forum.ubuntu-fr.org/viewtopic.php?pid=3431624

We (myself or the orignal poster) will add a comment here if Network Manager encounters the same issue with its calls to gnome-keyring.

> Do you mean a default *english* installation?

No, booting a french image of lucid, if the keyring is created by using empathy for example it's named "default.keyring", the issue is only happening when ubuntuone-client is the first keyring client to be started

Many thanks Sebastien.

I confirm that your workaround works fine.
I'll post your suggestion on the french forums, so that french people can now enjoy Lucid with all the stuff going to keyring:
- U1,
- NM
- Empahty
- etc...

Nevertheless it does not prove that there is no bug in gnome-keyring. It just demonstrate that when gnome-keyring is called with a filename that is ONLY ASCII 7, it works fine, which we already knew in previous versions.

But unfortunately, as Rodney pointed, somebody had the not-so-good idea to translate filenames, and in some case they have non-ASCII 7 characters, and should be handled properly as UTF-8.

Sorry I didn't take time to download and try to understand the code from U1 to Gnome-keyring, but my questions stays:

- do gnome-keyring handle UTF-8 filenames (maybe specification says it does not... and thus client calling it with UTF-8 is buggy)
- is specification says that gnome-keyring works with UTF-8 filenames, try to call it with filenames having letters outside ASCII7 and see if there is no bug.
- if at this point there is no bug, it is most certainly the caller that has a poor handling of UTF-8, of that kepts somewhere, hardcoded, filenames like login.keyring/default.keyring

Anyway, thanks again Sebastien, with your suggestion this bug is not "blocking" anymore for some components of Lucid (U1).

> - do gnome-keyring handle UTF-8 filenames (maybe specification says it does not... and thus client calling it with UTF-8 is buggy)

it seems it doesn't handle those correctly or this bug would not be opened

> - is specification says that gnome-keyring works with UTF-8 filenames, try to call it with filenames having letters outside ASCII7 and see if there is no bug.

there is no specification about that but gnome-keyring should either refuse to create a keyring with a name if this one is incorrect or handle it correctly so either way it's a bug

> - if at this point there is no bug, it is most certainly the caller that has a poor handling of UTF-8, of that kepts somewhere, hardcoded, filenames like login.keyring/default.keyring

there is still a bug, or at least the client has no reason to translate the keyring naming it's using, it's asking for trouble if the user ever change locale for example

> > - do gnome-keyring handle UTF-8 filenames (maybe specification says it does not... and thus client calling
> it with UTF-8 is buggy)

> it seems it doesn't handle those correctly or this bug would not be opened

Wow... a program written in the 21st century that do not handle UTF-8. Shouldn't we fire the one that built the architecture of that!

I share your analysis
- about the fact that gnome-keyring should still do proper things when handled a filename it does not support.
- and indeed I wonder why the filename was localized. It doesn't help either when you read documentation to try to understand things, as most of the documentation is written in English, and would probably mention this file as "default.keyring" which you wouldn't find on a systems with French, Greek, Russian, etc...

About this bug, something has to be done as currently, without the workaround you suggested, Ubuntu One is broken in most non-english Ubuntus. Network Manager, although not broken, is annoying and keeps asking you for the password of you Wifi as it cannot retrieve the previous keyring file (yet to be fully confirm as I don't have Wifi myself, and it's illegal to crack you neighbour Wifi, even for the sake of a test!)

Considering that gnome-keyring is unaware of UTF-8, isn't the simpler thing reverting to the English name for that file: default.keyring

And about gnome-keyring, should I open a "bug" or "suggestion", to urge them consider UTF-8?

hey there
something interesting here .
update everything includes the 2.6.32.22

fresh installed ubuntu ,everything work great no problem with network manger.

i was installing upek fingerprint sensor and after i install it , it was working perfectly .

the problem with network manager (nm-applet)began :
first i cant connect (every time i press on the icon ,it freeze)
after restarting the nm-applet icon doesnt appear (or it appears after minutes but frozen)

so i restarted and loaded the 2.6.32.21 kernel
nm-applet runs with some lateness and it see my wifi network and ask me for key, after i put the key and press enter the networkmanager freeze for all.

it look like the fingerprint libpam stuff has changed something in keyring ,and nm-applet cant get access to start (or even ask for the key)

the issue is not a desktopcouch one

upstream got a fix in git now which will be backported to lucid once confirmed to work in the maverick upload

This bug was fixed in the package gnome-keyring - 2.92.92.is.2.30.3-0ubuntu2

---------------
gnome-keyring (2.92.92.is.2.30.3-0ubuntu2) maverick; urgency=low

  * debian/patches/90_git_keyring_encoding.patch:
    - git change to fix an encoding issue in the default keyring name storage
      (lp: #553759)
 -- Sebastien Bacher <email address hidden> Tue, 27 Jul 2010 15:32:05 +0200

the change has been uploaded to lucid now

Trivial patch, easy to test, and gets quite some bad press, so marking for the point release. We are still waiting for mysql anyway.

Accepted gnome-keyring into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I've managed to reproduce the bug on a Lucid French installation and can also confirm that the proposed package fixes the issue, marking this as verification-done, thanks all.

This bug was fixed in the package gnome-keyring - 2.92.92.is.2.30.3-0ubuntu1.1

---------------
gnome-keyring (2.92.92.is.2.30.3-0ubuntu1.1) lucid-proposed; urgency=low

  * debian/patches/90_git_keyring_encoding.patch:
    - git change to fix an encoding issue in the default keyring name storage
      (lp: #553759)
 -- Sebastien Bacher <email address hidden> Wed, 28 Jul 2010 17:45:40 +0200

I've confirmed the fix on another lucid installation there as well now

With a lucid install updated as of 2011/01/11, I still face the bug.
The package version is 2.92.92.is.2.30.3-0ubuntu1.1

Whenever I start a session, the NetworkManager (wich is the first in my case to try accessing the keyring) creates a par_défaut keyring.

Any subsequent access to it fails. Even adding a password manually fails in seahorse with 'no such keyring like' message.

I confirm what Bruno Leon stated. This bug is NOT fixed.

With package

gnome-keyring 2.92.92.is.2.30.3-0ubuntu1.1

a default keyring file omissão.keyring (note the tilde...) is created when I launch, for example, Evolution.

With this default file keyring usage is broken. Every program is asking for the password.