Re: gnome-keyring Initial whack at dbus interfaces

[Stef Walter <stef-list memberwebs com>]

Thanks for your response. I hope it's okay that I CC the gnome-keyring
mailing list.

Michael Leupold wrote:
> On Wednesday 25 March 2009 04:50:22 Stef Walter wrote:
>>>>  * 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?
> 
> Actually I think I was wrong. I hadn't had a look at the actual storage format 
> yet and was just confused by the terms used. Now I figured attributes are 
> "secure" as well - and I guess they would also be transmitted encrytepd, 
> right?

That hasn't been the plan. Ideally attributes would not be encrypted at
all. It's very advantageous to be able to use attributes to search for
secrets even when the keyring is locked.

gnome-keyring does this by storing a hash the value of these attributes
without encrypting them. But for obvious reasons (think rainbow tables)
that's a joke security-wise.

It'd be really awesome to keep the single secret per item as the only
secret in the system. Is there a case where this won't work?

> I quoted the wrong function. afaik this timeout will happen for every of the 
> dbus methods you send with:
> "If -1 is passed for the timeout, a sane default timeout is used. -1 is 
> typically the best value for the timeout for this reason, unless you want a 
> very short or very long timeout. There is no way to avoid a timeout entirely, 
> other than passing INT_MAX for the timeout to mean "very long timeout." 
> libdbus clamps an INT_MAX timeout down to a few hours timeout though."
> (dbus_connection_send_with_reply)

Yes the dbus-daemon has its own timeout which is not controllable from a
client. However in reality, a couple hours delay could be acceptable for
 our various calls. Our timeouts are waiting for interaction from the
user and if the user doesn't respond for hours, then I think a timeout
is acceptable, no?

> I found this related bug that fixes these issues but it doesn't seem like it 
> has been applied yet (and I don't know if it will): 
> http://bugs.freedesktop.org/show_bug.cgi?id=16841

I have faith that these sort of things will be fine tuned in dbus as
time goes on, and that we can live with the INT_MAX (clamped down)
timeouts for now. Or is this unrealistic for some reason that I'm missing?

>>>>  * 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...
> 
> I know what you mean. I have been hesitating to change kwl files due to the 
> same reasons :) not sure how to handle this. neither allowing string nor byte-
> array as encrypted secret will give you a guarantee what it will look like if 
> you decrypt it. This implies that keyring will either have to reject non-
> string secrets or save byte-arrays. The latter seems preferable though.

You're right. Sending the encrypted data as a string has no bearing on
the contents. So the DBus interface should do byte-arrays.

But I still think mandating textual secrets could be very beneficial.
The checks for this would have to be done in the daemon, and obviously
the argument types of client APIs.

Reasons why:

 1. We can keep our file formats.
 2. Our GUIs can display many (most?) secrets in a meaningful way if
    they're textual (ie: seahorse).

Apps that need to store binary can base64 encode it. Obviously any GUI
display of this would not be meaningful to the user, but these should be
the exception, and we can't really help that.

It's great discussing this. Anything else we're missing?

Cheers,

Stef