Re: gnome-keyring Initial whack at dbus interfaces

[Stef Walter <stef-list memberwebs com>]

Michael Leupold wrote:
>> One or two other things:
>>  * Added, Removed, Changed signals needed.
> 
> Yeah, that would be great. Created/Unlocked/Locked signals will be very useful 
> as well. Like this the client will be able to display what's going on.

Yes that's true. Good point.

>>  * The 'fields' arguments and properties are hash tables of
>>    string -> string (name -> value). Integer fields and other
>>    types of values are encoded (in a canonical way) as strings.
> 
> Do you already have an idea how to work with items that contain several 
> secrets? I seem to remember you mentioned that once.

I don't remember mentioning it. I'm not sure that we want this. First of
all it would have to break the gnome-keyring file format.

But more importantly, it would complicate the model. If an application
wants to store multiple secrets associated with one another, it can
create a collection and put a bunch of items in there.

Is there a specific use case you're thinking of?

> There's a problem with the "indeterminate" which I was facing in kwallet as 
> well. dbus_connection_send_with_reply_and_block can not be called with an 
> infinite timeout. The approach we used to work around it was using an "unlock" 
> message call that returns a handle identifying the unlock-operation (before it 
> completes) and a signal using that handle to notify the client of the keyring 
> successfully unlocked. Of course you could also just use a huge timeout, but 
> that seemed rather unclean and the chance of any given unlock operation 
> failing was still there (and I would have needed to taken care of it in the 
> client code).

This really feels like papering over problems in DBus. DBus already has
tons of handling of mapping replies to messages etc... By making our API
this way we basically are implement RPC over the top of DBus again, and
every application (or library) that uses our interface has to try and
get it right.

In addition most GUI applications shouldn't be using
dbus_connection_send_with_reply_and_block. That's just asking for a
locked up UI. Any GUI app that does that is basically gambling with the
responsiveness of its UI.

So apps should always use async dbus calls anyway. So if we were to make
Unlock (and Find) async then we have two levels of "asyncness" on top of
each other.

There's also race conditions, to worry about. And if you really want to
handle it properly you need to handle cancel and timeout events in this
upper async API (ie: unlock-operation).

An interesting read that sort of along the same lines:

http://lists.freedesktop.org/archives/dbus/2008-July/010151.html

I guess if we run into problems designing a usable API WRT to timeouts,
we can bring it up on DBus list.

>>  * Secrets are transferred as a pair if strings, the first contains
>>    cipher specific parameters (ie: IV etc.)
> 
> I'd use a byte-array for the secret as it frees the implementation from having 
> to convert everything to base64 or similar (string has to be valid utf-8). So 
> that would be "(say)" I guess?

Yeah, I think a byte-arry is best too. However the gnome-keyring file
format (not designed by me) is limited to strings, and I'd really like
to not have to break compatibility.

It's a great goal not to break file format compatibility for users, but
perhaps if there is an overwhelming amount of reasons...

Cheers,

Stef