gnome-keyring keyring brainstorm [Was: Re: Initial whack at dbus interfaces]



On Thursday 26 March 2009 22:41:25 Stef Walter wrote:
> Michael Leupold wrote:
> >>> On Wednesday 25 March 2009 04:50:22 Stef Walter wrote:
> >>
> >> 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 was just thinking about storing eg. username/password pairs where you
> > want to keep the password secret as well. How is this currently done in
> > keyring? do applications store the username as a field or inside the
> > secret using some special format? KWallet currently allows the storage of
> > maps (string->string) of secret values for that purpose (basically just a
> > data-structure serialized to a binary blob used as the secret).
>
> Would it work to continue doing it this way? Is this the KWallet
> default, or an optional thing?

It's the what konqueror uses for storing form data on web pages, probably 
mostly because putting all non-secret fields' names and values into the item 
name (KWallet doesn't provide attributes, just one name) makes it look strange 
when editing :) Most other applications just use a secret string. With those 
KWallet operates pretty similar to keyring. Item names (= mangled attributes) 
are stored as hashes for searching as well as in the secret part.

> FWIW, it's worth noting that in most protocols the user name is not (and
> is not treated as) part of the secret.

Yes, but taking this possibility away from people who are used to it will 
still be perceived as a loss of security, no matter what. :)

> >>> 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?
> >
> > Yes, that can be worked around but there's some places you have to take
> > care of that. I was mentioning it because I had quite a time trying to
> > fix the DBus version of kwalletd (DCOP didn't have that issue afaik).
> > It's possible but it's no fun :)
>
> Was that mainly because the clients used the default timeout?

Partly, yes. At least that's how I stumbled upon the bug. For all KDE 
applications I can however adjust the timeout because they're using an API 
wrapping the DBus calls instead of calling DBus directly.

I remember the following things that were inconvenient to implement:
- The client API has to be adapted to take care of timeouts. Care has to be 
taken wether to react the same as for a failed Unlock (doing it will relieve 
relieve clients using the API of handling the timeout).
- The dialog asking for the password has to disappear on timeout
- .. but there might be other queued (not-yet-timeout) requests waiting for 
the Unlock to finish which need the dialog
- There might have been an issue with detecting the timeout on the server-side 
but that might have been qt-specific (I just don't remember exactly)

Overall manageable, but it adds extra complexity that has to be taken into 
account. I think the easiest way of implementing it (without the asynchronous 
stuff I mentioned earlier) would be to not handle timeouts in a special way 
(timeout = failed unlock, eg. too many failed password events) and setting the 
timeout to INT_MAX. Then we can poke the DBus people for no-timeout 
send_with_reply :)

I finally came up with two other things I had been wanting to implement for 
KWallet:

(1) syncing collections (aim: multiple PCs):
As keyring already provides mtime this should be a matter of providing a GUI 
for it.

(2) multiple methods to unlock a collection:
I think it would be awesome if we could provide a way to unlock a keyring not 
only using a password but also using a smartcard (and possibly even 
biometrics) - if possible several authentication methods on the same keyring. 
This would however require the format to be changed as well.

Regards,
Michael

Attachment: signature.asc
Description: This is a digitally signed message part.



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