Re: cleaning up keyrings

["Havoc Pennington" <hp redhat com>]

Hi,

On 8/29/07, Stef Walter <stef-list memberwebs com> wrote:
> 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.

You're talking about http auth here, I'm talking about the feature
where Firefox fills out your login in the html page. ("password
manager" - see that mozilla wiki link I sent in the original post,
which describes the schema)

http auth can probably use the NETWORK_PASSWORD type as nautilus does for DAV.

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

It may also be due to total lack of any docs ;-)

I think maybe it would be better to do something like:

 - have a super-convenient, simpler API for the normal app use case:
store, list, and delete

 - split this API out to the top of the file with a big comment
   USE THIS STUFF ------>
   and then another after it:
   IGNORE ALL THE REST OF THIS ---->
  ;-)

 - also have a comment/docs describing the property names to use for
some of the common schemas I just mentioned

Anyway, the point is do a convenience API that just makes it simple to
use the property names, and then rearrange the header and docs so you
just see the few things most apps care about and don't have to try to
dig through that huge gnome-keyring.h header. Most of the API is only
useful for a keyring manager and other obscure cases.

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

That's my opinion, if only because realistically apps are not going to
port to store their main list of accounts in gnome-keyring, and
there's no real benefit if they do anyway. I'd say keep it simple and
say gnome-keyring is just for secrets.

Here's a sketch of what I think a simpler API might be like:

enum {
  KEEP_IN_MEMORY,
  SAVE_TO_DISK
} StorageScope;

char *the_secret_data = "top secret";

/* store a secret, so it can be looked up using the provided properties */
store_secret(SAVE_TO_DISK, the_secret_data, "username:string", "hp",
"port:int", 80, "server:string", "example.com", NULL);

/* load all secrets matching the provided properties */
KeyringSecret **secrets = load_secrets("username:string", "hp",
"port:int", 80, "server:string", "example.com", NULL);

/* delete all secrets that match the provided properties */
delete_secrets("username:string", "hp", "port:int", 80,
"server:string", "example.com", NULL);

/* delete a specific secret */
delete_secret(secrets[0]);

char *my_secret = secret_get_secret(secrets[0]);

/* not even sure this is needed... should already be known to the app */
char *username = secret_get_string(secrets[0], "username");

Concepts the app developer could avoid knowing to use this simpler API:
 - KeyringResult
 - KeyringItemType
 - AttributeList
 - KeyringFound
 - default vs. session
 - create/delete non-default keyrings
 - item IDs
 - ACLs
 - special "network password" schema and related API/datatypes

those are all useful sometimes, but not needed in a convenience API.

Havoc