Re: disabling keyring

[Éric Brunet <Eric Brunet lps ens fr>]

On Tue, Oct 25, 2005 at 03:52:35PM -0400, Christopher Aillon wrote:
> >>in gconf. You will find the patch at http://tudia.nerim.net/nm/ with a
> >>binary rpm built for fedora.
> >>    
> >
> >With all due respect I'm opposed to this patch. Please don't commit it. 
> 
> Of course not, it won't be committed.  In fact, this RPM will keep 

Oh, I am sorry that I wasn't clear: I certainly did not propose this
patch for inclusion. It is merely a quick hack to have something working
again. I made it for my own personnal use and I thought that some other
people could be interested in it, that is all.

> getting obsoleted with each new RPM build that Fedora pushes out so its 
> existence will be a disservice to users of this patch.  These users' 
> keys will be switching between GConf and the keyring in between 
> updates. Realistically, This patch will never make it into gnome CVS or 

This is of course true. Actually, I don't intend to upgrade
NetworkManager for a looong time, now. As it is now, it ``just works''
for me, and that is all I ask. (Note that, while it wouldn't make sense
to have such a patch in NM tree, it might make sense for distribution to
use it till gnome-keyring is fixed. Furthermore, even with a
gnome-keyring enabled NetworkManager, it might make sense to use a key
from gconf if one is present, even if NM itself would never write a key
in gconf.)

> Fedora, and I'd much rather see resources going into fixing the real 
> issue, which is in gnome-keyring.

If I may articulate one or two suggestions about NM in the long term,
I think that storing keys in home directory is not the good direction.
NM is designed mainly for laptop use, and laptop are usually used by
one or a small number of people well knowing each other (like a family).
If Alice configure a home wireless access point, then gives the password
to NM while logged in as Alice, I would find it normal that her younger
brother Bob and her boyfriend Charlie, who both have an account on this
machine, have a working network the next time they log in. Alice is root,
too, and when she launches her gnome/kde as root (bad bad bad, but
then...) I would expect that the network works there too. As it is now,
everyone has to setup NM for oneself or, more realistically, Alice will
have to use root's power to log in as everyone and set up network for
them. Not nice.

In fact, I don't quite see a plausible situation where you might want
that, on a laptop, two different users have some different network keys
and privilege. And if it happens, I don't believe it is the general rule.

What I would find more logical is that NetworkManager itself manages the
network informations and keys, storing them in someplace neutral
(/var/NM/something) in files belonging to root (or some special id). This
way:
	* key entered by one person is available to everybody
	* the network can be up while noone is logged in. This is a nice
	  feature for debugging a computer, or if the computer runs a
	  mail/web/file server (why not on a laptop connected by wifi).
	* when the user log in, he can immediately use the network and 
	  does not have to wait 15 sec for nm-applet to launch, retrieve
	  the key, communicate to NetworkManager which does a dhcp, etc.
	  Come on, everybody in the linux world tries to reduce the boot
	  time. Waiting after login 15 sec to have network up is very
	  much like having a boot time 15 sec longer !

If, for some raison, it is needed to have some network keys available to
one user and not another, this can be added later (a checkbox in
nm-applet saying ``this key is private''). Why not. But I don't see why
it should be the default.

Well. I suppose all of this has been discussed and debated already, and
that there is a very good reason for the current design...

>                                    Anyway, don't assign a password to 
> something and then get surprised when you get prompted again for it.

Won't happen, 'cause I won't upgrade.

Regards,

	Éric Brunet