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.