Re: Using Separate Keyring

[Jon Nettleton <jon nettleton gmail com>]

On Tue, 2006-06-27 at 13:58 -0400, Pat Suwalski wrote:
> Jon Nettleton wrote:
> > The reason it is not designed like this is for security.  If firefox
> > stores it's passwords in a keyring ( it doesn't yet ), and you download
> > random spyware/virus from the web and launch it, with the cookie jar
> > method the rogue program would have access to all your web passwords.
> > Right now you would get a pop up, or maybe twenty that ask if that
> > random program should be allowed to get this information. 

Take a deep breathe...phew now isn't that better.
>  
> 
> Then FireFox wouldn't use this functionality. They would ask one key at 
> a time, like the current implementation does. But it should be possible 
> for a program to ask for access to a whole keyring. That's why it's 
> called a keyring: you typically hand the entire ring to someone, not 
> just one key.

It is called a keyring because it holds many keys.  Personally I
generally only give a person a single key from my keyring.  When someone
is borrowing my locker at the gym, I also don't give them the keys to my
house and car at the same time.  Semantics I know but let's keep our
perspective about the problem.

> 
> For wireless security, it's even sillier: I thought it ridiculous when 
> the XP SP1 interface started hiding the WEP key being entered. Only 
> hiding the password on a proper certificate makes any sense, as that is 
> actually personalized data, often based on a real login u/p.
> 
> Security gets in the way of a good user experience far too often under 
> Linux. This is why things like NetworkManager exist.

You say this and yet how many voices cried out in anger when
NetworkManager started using gnome-keyring to store their keys.  The
balance between security and usability is a give and take process.  We
are all doing our best to make things work as seamlessly as possible
without ending up with Windows 98.

> 
> Regardless, it would be nice to have the keys in a separate keyring so 
> that they're grouped together. Maybe some day it will be possible to 
> access the entire keyring.
> 
> > Then interface that I started working on for the ACL dialog doesn't
> > completely fix this problem, but intends to reduce the confusion.
> > Envision that for a single application to access all items in a keyring
> > you will get a dialog that pops up that has all the items listed with
> > checkboxes next to them.  Then you will have buttons for allow to
> > selected for this session, always, deny.  Anyways you kind of get the
> > idea.
> 
> This doesn't help me much, since I don't necessarily want to load all 
> the items at once. In fact, because this is a separate process, I want 
> to load as little as possible to prevent a local cached copy of the data 
> going out of sync with nm-applet.
> 
> I see it as:
> - User starts editor
> - gnome-keyring asks for access to 'wireless' keyring
> - As user clicks around, information is loaded on an as-needed basis
> 
> Right now it's like this:
> - User starts editor
> - If first AP in list is not WEP-less, they get a gnome-keyring message
>    asking for password/access.
> - They click on the next item, the above step repeats.
> 
>  From a user's point of view, it borders on ridiculous. "Just give this 
> program access to all the wireless keys, dammit!" is what they'll be 
> wishing for.
> 
> Your approach would not be very useful to nm-applet either unless it 
> loads all the encrypted networks in one shot, which I don't think is a 
> very good idea. It also makes it a heck of a lot more work to make the 
> editor apply changes in a way that they are visible to the applet.


I am sorry to have wasted your time I did not understand from your other
emails what your use cases were.  My suggestion would be to file a RFE
bugzilla at bugzilla.gnome.org.


> 
> --Pat