Re: gnome-keyring branched

[Jon Nettleton <jon nettleton gmail com>]

On Fri, 2006-04-21 at 11:15 +0800, James Henstridge wrote:
> Jon Nettleton wrote:
> > On Fri, 2006-04-21 at 08:59 +0800, James Henstridge wrote:
> >   
> >> Nate Nielsen wrote:
> >>     
> >>> Jeff Waugh wrote:
> >>>   
> >>>       
> >>>> <quote who="Alexander Larsson">
> >>>>
> >>>>     
> >>>>         
> >>>>>> Any grand and glorious plans for 2.16?
> >>>>>>         
> >>>>>>             
> >>>>> Not really. Jon Nettleton is working on pam-keyring[1], so some work
> >>>>> required for that is going in.
> >>>>>
> >>>>> 1) http://www.hekanetworks.com/pam_keyring/
> >>>>>       
> >>>>>           
> >>>> That's very exciting! Has anyone been working on kerberos, gpg or ssh love
> >>>> for gnome-keyring?
> >>>>     
> >>>>         
> >>> Yup, I'm getting a bunch of code that does exactly this ready for
> >>> inclusion in Seahorse (which manages GPG and SSH keys).
> >>>
> >>> There's also gnome-gpg, which integrates GPG password prompting into the
> >>> keyring.
> >>>   
> >>>       
> >> I haven't looked at the seahorse code much, but if gnome-gpg and
> >> seahorse are storing PGP passphrases in the keyring it would make sense
> >> to use the same key names so that the user doesn't need to reenter their
> >> passphrase for each app (they'd still need to authorise the app to
> >> access the key though).
> >>
> >>     
> > Not that I want to OT this thread too much, but hi all.  I was mentioned
> > earlier in this thread because I am working on getting pam_keyring fully
> > integrated with gnome-keyring and pam.  I think we are really making
> > some good strides.
> >
> > Relating to the last post, I wanted to ask, "What does everyone see as
> > the future implementations of gnome-keyring?"  
> >
> > Personally I want an infrastructure where every application can have
> > their own keyring, ie.  NetworkManager, Gnome-PGP, Gnome-VFS, e-mail
> > (Evolution, TinyMail, Thunderbird), Web Browser ( Epiphany, Firefox,
> > Mozilla).  The sky is the limit.  Gnome-keyring really then acts as a
> > manager to give all the applications good seamless integration to secure
> > storage of passwords.  
> >   
> I'm not sure that it really helps to have separate keyrings for each
> application.  Provided that applications use enough information to
> uniquely identify the keys it shouldn't be necessary.  If seahorse and
> gnome-gpg were using the same key names for PGP passphrases, we'd get a
> workflow something like this:
> 
>    1. user enters the passphrase for their PGP key in seahorse to
>       decrypt some mail, and asks seahorse to save the passphrase in the
>       keyring
>    2. user then uses gnome-gpg to sign or decrypt something (e.g. sign a
>       commit with bzr), which asks gnome-keyring if it has the passphrase.
>    3. gnome-keyring asks the user if they want to allow gnome-gpg to
>       access the passphrase (since the key wasn't added to the keyring
>       by gnome-gpg).  If they say yes, then the passphrase is returned
>       to gnome-gpg.
> 
> What would be the benefit of gnome-gpg and seahorse using separate
> keyrings in this situation?
Perhaps I was not clear enough.  I wouldn't expect them to use seperate
keyrings.
> 
> Similarly, if evolution and tinymail use enough attributes to search for
> mail account passwords (protocol, hostname, port number, username), then
> there would be obvious benefits to sharing the same keyring.
> 
This is exactly what we would want.  I guess a better classification for
keyrings would by by application type.  If all the email clients stored
their account secrets in gnome-keyring the same switching between them
would be less painful.  The same would hold true for web browsers, or IM
clients.  I think separating them makes sense because you might want to
move just carry around a copy of just your email passwords on a USB
keyring to use on another computer.

> The place where it does make sense to use multiple keyrings is where
> different policies are involved, as with the current default and session
> keyrings (the contents session keyring is not saved past the end of the
> session).

I agree with the policies point as well.  One bugzilla right now is
about why when you register access to a key in nautilus do you have to
then authorize it again for gnome-panel that is just a shortcut to
nautilus.  I think breaking up keyrings will allow us to make prebuilt
ACL's for types of keyrings more flexible without giving up a lot of the
security the system is striving for.

Jon