On Thursday 26 March 2009 05:21:30 Stef Walter wrote: > Thanks for your response. I hope it's okay that I CC the gnome-keyring > mailing list. Yes, of course. I forgot doing that again as gmail seems to only keep the mails you cc to me privately and somehow merges them with the mail on the 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 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). > > 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 :) > >>>> * 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? I was planning to have a closer look at keyring and compare it to my list of nice-to-have features for KWallet as well as our current featureset (to allow for smooth transition or some wallet->keyring dbus wrapper API) this week. So far there's nothing I could think of. Kind regards, Michael
Attachment:
signature.asc
Description: This is a digitally signed message part.