reopen 449501 thanks On Sun, Dec 02, 2007 at 10:12:11PM +0100, Michael Biebl wrote: > Mike Hommey schrieb: > > On Tue, Nov 06, 2007 at 11:52:34AM +0100, Michael Biebl wrote: > >> Mike Hommey schrieb: > >>> On Tue, Nov 06, 2007 at 11:19:55AM +0100, Michael Biebl <[EMAIL > >>> PROTECTED]> wrote: > >>>> Mike Hommey schrieb: > >>>>> reopen 449501 > >>>>> thanks > >>>>> > >>>>> I think there *is* a n-m-g bug : why does it need the keyring while it > >>>>> obviously got the key without it ! > >>>> That's impossible. Maybe you unlocked it using pam_keyring or > >>>> libpam-gnome-keyring. > >>> I wonder if it actually doesn't get help from the wireless driver, since > >>> it is reassociating to the same AP with the same key it was using before > >>> hibernation. And the keyring dialog does say nm-applet is requesting > >>> access > >>> to the keyring. > >> n-m does not keep the key in memory. In addition, on suspend/hibernate > >> the network devices are put to sleep, so they need the key again on > >> resume. So it is to expect that n-m-g asks gnome-keyring for the key again. > >> I don't yet see where the bug in n-m/n-m-g is? > > > > [..] > > > > > So, obviously, n-m has been able to use a key it had in memory. Now, why > > does n-m-g asks the keyring ? > > Ok, I was wrong. n-m-g does keep the keyring in memory. > What happens this: > /apps/gnome-power-manager/lock/gnome_keyring_hibernate is true in your > case so g-p-m closes the keyring on hibernate. > On resume, n-m-g reestablishes the connection (using the key in memory). > Whenever n-m-g successfully establishes a (encrypted) connection, it > will safe/sync the key in the keyring so it can reuse it in the future, > that's why it opens the keyring after resume and after successfully > establishing a connection. > Imho this behaviour is correct.
IMHO, this behaviour is not correct. It should not keep the key in memory. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
