On Tue, 2007-04-17 at 04:43 +0000, Nate Nielsen wrote: > Jon Nettleton wrote: > > The above approach also gives you the ability to have different > > passphrases for different certs, or services. They are retrievable if > > you forget them but remember your system passphrase. It also gives you > > only one passphrase (the one to unlock the Login keyring) to keep in > > sync with your system passphrase. So if something happens and they get > > out of sync you don't have to update 20 different passwords to get > > things back sync'd up and unlocking on login properly. > > Cool idea. It's a good solution to multiple keyrings, unlock on login, > and things like key store integration. It also helps users with simple > needs keep things simple, while security minded users can have > uncompromising security. > > But I have a few suggestions to help simplify things slightly... > > A. Let's not expose the 'Login' keyring as a normal keyring. I don't > think other applications should be allowed to mess with it. We > might consider it a implementation detail internal to > gnome-keyring-daemon. For simplicity we might call it something > like 'master passwords' in the code.
The contents should have the ability to be displayed by whatever management program is being used. I want this only so a password that hasn't been changed or entered in years isn't gone forever and the contents of the keyring locked unrecoverable. Other than that I completely agree. Basically we would just check if the on_login property of a keyring was set and internally have the gkd add or remove it from the Login, or 'master passwords' keyring. > > B. Any keyring, key store, etc. that has a valid password configured > in the 'master passwords' would be unlocked upon login. I think this would be best accomplished by exposing a simple function in the libgnome-keyring api. Have something like gnome_keyring_unlock_masterpassword_keyring and gnome_keyring_unlock_masterpassword_keyring_sync that would take the password to use, or NULL to be prompted. > > C. When the user changes the password to their keyring, they'd have > the option to choose whether it gets unlocked upon login or not. > In effect they'd be choosing whether the keyring password would > be stored in the 'master passwords' or not. This would need to be exposed in the gnome-keyring-ask gui, probably just a simple checkbox should be fine. > > D. Initially the first default keyring for a new account would be > encrypted in the same password as the login password (ie: and > the same as 'master passwords' is encrypted in). This allows > people who absent mindedly move keyrings or certificates to a > different system to use a password they know to access them. I will go with this. Should this be a function of gnome-keyring-daemon? So the gkd would launch, oh there is no default password and immediately try to create a default, and 'master passwords' keyring? > > You've obviously thought about this a lot, so there may be things I'm > missing in my suggestions above. But I think that implementing it in > this way would simplify things for both users and developers. Thanks I am glad you like my ideas. Now I just need to get my butt in gear and finish up all the half done code I have been sitting on. Jon > > Cheers, > Nate Nielsen > _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
