Re: gnome-keyring branched



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?

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.

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).

James.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]