Alexander Larsson wrote: >> In fact an application would need to have coded special support for >> using any second keyring within the same user session. > > Not really, key lookups always happens in all keyrings. You would need > to set the default keyring to something when saving the passwords, and > then change the default to another keyring, but after that all apps > should be able to read passwords from both keyrings.
Interesting. But in this case it's exactly the set-default-keyring functionality that complicates things. > I'm not against removing this functionallity. I think it mostly came > from me looking at other keyring implementations when doing the initial > design. > > How does it complicate the design though? Well I'm looking into putting one or more types of key/certificate store into gnome-keyring. Keys will most likely be stored in their own file(s) rather than the gnome-keyring password/secret store. [1] I'd like to encrypt secret keys in this store with the same 'master password' as the user's keyring. This way the user doesn't have to type yet more passwords during login. When the user changes the 'master password', we re-encrypt the key store with that new 'master password'. [2] When there are multiple 'master passwords' (due to multiple keyrings) and they can be flicked around easily by an unsuspecting user, there is a whole bunch more logic that needs to be worked out, and a bunch more bugs, and lost/inaccessible keys [3]. I think it's imperative that this functionality remains conceptually simple. This will help it 'just work' for admins and users. I'm also looking forward to the possibility of including SSH agent functionality in gnome-keyring (similar to how Mac OS X KeyChain works) which again, would need a single key store (in ~/.ssh), with private keys encrypted by the gnome-keyring 'master password'. So again, in the end, what I'm proposing to remove is the gnome_keyring_set_default_keyring() functionality. From your explanation, this will essentially limit saving of passwords in multiple keyrings to applications which are coded to support it. More design info here: http://live.gnome.org/GnomeKeyring/Cryptoki Cheers, Nate Nielsen [1] Keys behave very differently from the passwords/secrets that gnome-keyring-daemon is currently storing. The 'secret' never actually crosses the wire. Instead applications send bits to encrypt or sign to the daemon where the operation is performed. This is usually a simple session key. [2] Another approach is to encrypt the key store with a different randomly generated password and then put that password into gnome-keyring's password list. However if the key store ever becomes separated from gnome-keyring (think backups), the keys are useless and gone forever. [3] Lost or inaccessible (private) keys are probably the single worst possible thing that can happen in a key store. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
