Re: cleaning up keyrings

Havoc Pennington wrote:
> 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

Sadly an HTTP login is far more complex than just that. In basic and
digest authentication 'realm' is sent from the server, which is really
what defines which login to use.

Also digest authentication has the concept of a 'domain', which is the
URI prefixes with which a login should be automatically used.

> 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)

If we want we can make additional gnome keyring item types, but these
would need to be fairly far well established groupings. It may be that
we add an item type for IM accounts, another for email accounts, etc.

I think one reason people are using the network password type is because
there are gnome-keyring convenience APIs for using this type.

> 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.

Yes, the main limitation is that of one secret per item. If you wanted
to use it for account data that would be possible with that limitation.
The ACL infrastructure (where applications can specify something as for
them only) might be handy when storing accounts.

But perhaps account data has a better life elsewhere, like you noted.

Stef Walter

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]