keyring-entry in gnome-keyring has unobvious description "network password"

Bug #738391 reported by Andreas Moog on 2011-03-19
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Markus Korn

Bug Description

Hi there,

currently, the authorization keys are stored in gnome-keyring under the name "network password". I think this should be changed to 'api.launchpadlib' and 'api.staging.launchpadlib' to make it easier to identify them. Thanks.

Robert Collins (lifeless) wrote :

This would be nice to fix before natty releases - I suspect changing it requires asking for new tokens.

Changed in launchpadlib:
status: New → Triaged
importance: Undecided → High
Leonard Richardson (leonardr) wrote :

Unfortunately this is not launchpadlib's value to set. "network passwords" are a standard feature of the GNOME keyring which the keyring module is taking advantage of.

To get the credentials to show up as top-level keys we'd need to set them as keys. I don't know how to do this, but Benji might.

We could probably create our own keyring backend that did this; we wouldn't necessarily have to change python-keyring.

Martin Pool (mbp) on 2011-04-12
summary: - keyring-entry in gnome-keyring isn't obvious
+ keyring-entry in gnome-keyring has unobvious description "network
+ password"
Markus Korn (thekorn) wrote :

I think at the end it's which caption clients like seahorse are using for each item in the keyring, keys are AFAIK not stored with any description.
seahorse seems to have three possible patterns for the description of a key, it's either of these:
Or, if <server> is NULL and the item is a network password the phrase "network password" is used.

Launchpadlib (via python-keyring) is using these values ATM:
  user = 'System-wide: <dist-name> (<username>)@https://<lp-service-root>/'
  domain = 'launchpadlib'
The 'server' field is not used, this is why user of seahorse see the generic description.

So if launchpadlib simply uses some value for 'server' seahorse would show something usefull. Unfortunatly python-keyring's GnomeKeyring backend does not support using the "server" argument, so launchpadlib has to subclass this backend. I propose using this arguments:
  user = 'System-wide: <dist-name> (<username>)'
  server = '<lp-service-root>'
  domain = 'launchpadlib'

Implementing a subclass of the GnomeKeyring backend seems to be a bit hackish, but possible in a few lines of code.

Markus Korn (thekorn) wrote :

The attached branch has a first version of a possible fix, see the screenshot for how the description of a key looks in seahorse

Martin Pool (mbp) wrote :

Thanks for tackling this, Markus.

I know the string didn't originate with you but I think "System-wide: " is a bad prefix to use here because unless I'm much mistaken it is not system-wide at all. It is per-user. I also doubt that it is particularly related to Ubuntu either: if I accessed the same keyring from Debian or Gentoo it would very likely work.

So I would suggest just

  user = lp_username
  server = lp_service_root_url
  domain = 'launchpadlib' (maybe? i'm not sure where that's used.)

If you want to propose your branch I will at least try to review it and Benji probably will too.

Markus Korn (thekorn) wrote :

Sure, I'm going to propose this branch for merging early next week.

Changed in launchpadlib:
assignee: nobody → Markus Korn (thekorn)
Robert Collins (lifeless) wrote :

@thekorn: ping

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers