[09:04]  * MacSlow -> errand
=== MacSlow is now known as MacSlow|errand
=== MacSlow|errand is now known as MacSlow
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
=== beuno is now known as beuno-lunch
[18:09] <davidbarth> DBO: ping?
=== beuno-lunch is now known as beuno
[18:51] <DBO> davidbarth, pong
[18:51] <DBO> ah 14 minutes, I was close :P
[18:56] <DBO> davidbarth, so the idea is to auto-unlock the keyring on UNR?
[18:59] <DBO> I mean the easiest fix is to default to the keyring having no password
[18:59] <DBO> I think loic mentions that in the bug
[19:05] <ScottK> Why bother with a keyring at all then?
[19:06] <ScottK> Isn't the point for it to have a password?
[19:06] <DBO> well you are talking about a situation where the user turns on the computer and it logs in for them
[19:06] <DBO> so indeed, why have a user password at all?
[19:07] <DBO> I am not suggesting this is secure. I am however suggesting that there is a conflict between usability and security here
[19:07] <DBO> and we already fell on the end of usability, we may as well take it all the way and at least get that right
[19:09] <DBO> it would be more useful to keep it encrypted but automagically unlock the keyring on an automatic login
[19:10] <DBO> maybe if we get NM to use a non-default keyring, we can have that get unlocked by default
[19:11] <DBO> or simpler still, just have that one have no password (always unlocked) and yes that presents a small issue, but not nearly the size of what I suggested above
[19:29] <proppy> DBO: I  set no password to my keyring, for skipping the dialog on wifi connection
[19:29] <DBO> proppy, I would bet 50% of affected users do that
[19:29] <proppy> IIRC
[19:59] <davidbarth> DBO: no (stop the flamefest ;) the idea is to adjust window Z order to let the keyring be revealed
[19:59] <DBO> huh?
[19:59] <DBO> okay I missed something
[19:59] <DBO> are we reading the same bug?