Re: Using Separate Keyring

[Pat Suwalski <pat suwalski net>]

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.  

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.

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.

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.

--Pat