Re: cleaning up keyrings

["Havoc Pennington" <hp redhat com>]

Hi,

I wrote down the "schemas" for the current information stored by
various apps. Here those are, essentially 5 kinds of object:

Firefox/Epiphany/etc. Browser Web Site Login
   Domain (exact domain:port we logged in to)
   Username
   Password
   Username Input Field Name
   Password Input Field Name

Mugshot/BigBoard Schema for Public Accounts
   Account Type (an enum with values like Flickr, Facebook, etc.)
   Handle           (meaning defined by the account type)
   Extra             (meaning defined by the account type)
   (Handle/Extra can have account-type-specific names like Username probably,
    they only need generic names when stuffed in a relational database)

GNOME Keyring Schema for File Shares (NETWORK_PASSWORD)
   Username
   Hostname
   Port
   Windows Domain
   Protocol (http, sftp, etc.)
   Object (i.e. random metadata string depending on type)
   Password (secret)

Gossip/Pidgin/Telepathy IM Account
   Account Type
   Username (for jabber, the entire username domain)
   Password
   Resource (jabber only)
   Server (jabber only)

NetworkManager VPN Key
   Human Readable Server Name
   Username
   Password (secret 1)
   Group Password (secret 2)
   (note that there are two secrets, so Human Readable Server Name and
    Username are in gnome-keyring twice; there are two items)

Observations:

1) stuffing the other four into the gnome-keyring NETWORK_PASSWORD
type is just wrong. NETWORK_PASSWORD makes no sense except for file
shares. I think the Gossip patch trying to use it is wrong and the
NetworkManager usage of it is wrong. They should use GENERIC_SECRET
and have their own sensible field names. (By using NETWORK_PASSWORD,
people are doing the equivalent of picking an existing, unrelated
database table for their new data, and if they have an integer they
pick some random column in the existing table that happens to be an
integer, and put their integer in there... even if it meant something
totally different before)

2)  There's a confusing thing about gnome-keyring, which is that it
stores metadata like account name, but *it stores one item per secret,
not one per account or whatever* - i.e. the metadata is just a way to
look up the secret. gnome-keyring can be abused to store the metadata,
but that isn't really the point of it. Really gnome-keyring is only
intended to be the canonical store for the password, and you'd have
some other storage for the account details.

3) To get the user experience benefits we want, an approach might be:

a) add separate APIs to list, watch changes in, and get named
properties of each type of object; this can be merged into the Online
Desktop data model perhaps. For each type of object the implementation
will be different, since we'll have to talk to or scrape a different
app. The point here is that BigBoard and other parts of the desktop
can get at the objects in a read-only way.

b) separately for each object type, we could also work on a shared
repo so if you create the object in one app it's available in other
similar apps. However, this may not be immediately necessary. This can
be thought of as making the APIs in a) into read-write APIs. But when
thinking of specific use-cases it's not clear that read-write is very
important, since a single app right now tends to canonically have each
piece of info (the app that provides the editing for the info).

c) use gnome-keyring only for the *secrets*. i.e. say you query the IM
accounts API, you would *separately* query gnome-keyring for the IM
password (if you needed it). We still need docs for gnome-keyring that
simply list the field names you can use to look up each secret.

4) making 3) more concrete:

a) would involve say writing code that exports the Firefox password
manager over dbus; code that sucks accounts from each IM app in a
generic way and makes them available as a single dbus API; code to ask
the browser and Mugshot about specific public account info such as
Flickr and Facebook.

b) would involve for example having a single file format or database
that stores accounts for all IM clients. I don't think this is
important. For now a common API is fine. What IM clients *could* do,
however, is use the API for getting web accounts or the API for
getting IM accounts, and try to auto-initialize accounts that can be
inferred from those others.

c) means modifying Pidgin, Gossip, Firefox, etc. to use gnome-keyring
*to store the passwords* - but NOT to store the actual _list_ of
stuff. i.e. they are only using gnome-keyring to store the one secret
field, while keeping their XML files and so forth as the master copy
of the other data. The second task under c) is to _document_ the
property names used to store each type of secret, and what those names
mean. This means that if two apps storing equivalent secrets use the
same property names, they will automatically share each other's
secrets.

5) for purposes of "make BigBoard magically know your mail/calendar
account" the important changes would be: exporting browser web site
login list over dbus; and making the browser sync the password part of
the list to gnome-keyring. At that point, if you were logged in to
GMail in the browser, BigBoard would know to log in to it also and
could get the password to do so from the keyring.

Havoc