Re: cleaning up keyrings

[Alexander Larsson <alexl redhat com>]

On Tue, 2007-08-28 at 18:23 -0400, Havoc Pennington wrote:
> Hi,
> 
> Thanks for the bug links, those are helpful.
> 
> Here are some questions I have about conventions for storing stuff in
> the keyring, which would be relevant to the Gossip bug (and future
> similar bug against Pidgin, etc.)
> 
>  - when do you use "default"/NULL vs. "session" keyring? (I think I've
> asked this before, but I forget)

I see stef replied to this. Basically, session means "don't save this to
disk".

>  - the Gossip patch sets user=havoc.pennington and server=gmail.com
> for my account, but why does it set "server" and not "domain", and
> when would something set "domain"? Is "domain" intended for web
> passwords only?
>  - what is the "object" field in gnome-keyring supposed to be for?
> NetworkManager vpn stuff sets it to "password" and "group_password",
> the Gossip patch doesn't use it
>  - Gossip patch sets "protocol" field to "jabber", NetworkManager to
> "org.freedesktop.NetworkManager.vpnc", ... ? when is this field used
> and what's its intended content?

First of all you have to realize that gnome-keyring is very free-form in
its objects. What you can do is map a set of key-value pairs (where
values are ints or strings) to a secret. And, when you query you query
for a secret you do so by passing a set of key-value pairs which will
return a list of matching secrets, ordered so that the most "specific"
comes first (i.e. has more keys set).

So, for instance, you could save with just the keys "type", "user",
"server". And then query only on "type" and "server", which will give
you all the users + secrets stored for that server.

So, back to the specific fields you're talking about above. They are
used by the helper function like gnome_keyring_set_network_password. All
these do is make it easier to handle "typical" network passwords. You
don't have to use these specific fields, or you could set them using the
lower level calls, its just a utulity functions. That said, here is what
the fields are used for in gnome-vfs:
				
user: the username
domain: Windows domains for the user (smb)
server: server hostname or ip number (as string)
port: the tcp port on the server
object: protocol-specific object reference:
     smb: the share name
     http: the authentication real
     sftp: ssh key name (for saving passphrases)
protocol: http/ftp/sftp/smb
authtype: for htp: basic or proxy, for sftp: password or publickey

The protocol field is basically used to define what type of secret this
is, so that when you add that as a filter you don't find other types of
secrets. I'd recommend to have this for all secrets. The rest of the
keys can be used (or not) in a per-protocol specific way that makes
sense for that protocol.

>  - I would think in Gossip or Pidgin you can create two accounts with
> the same username/password (true? or do they stop you?) - how would
> that be handled?

I'm not sure what you mean by this. Two accounts on different types of
IM systems? That would be handled by specifying more details than just
the user/password (like protocol, etc).

> Ideally I think we'd allow Gossip and Pidgin to ask something like
> "give me all XMPP accounts on the keyring," I guess that would use the
> "protocol" field? Would the results be sane if Gossip or Pidgin
> "merged" this resulting list of accounts with their own app-specific
> list of accounts? How should that merge be done? What if you delete an
> account in the app's account manager screen?

Its certainly possible to use gnome_keyring_find_items (or the helper
gnome_keyring_find_network_password) specifying only protocol=xmpp,
which will give you all the items where you can read both the username
and the other details and the password.

This is how a http authentication works in gnome-vfs. We only feed
gnome-keyring protocol=http, the server, port, authtype and the object
(the auth realm). This gives us a list (typically of lenght 1) where we
can read the username, as well as the secret password.