After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681576 - 3.5.5: Lock screen shows password for a few characters / max 1 second
3.5.5: Lock screen shows password for a few characters / max 1 second
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.5.x
Other Linux
: Normal blocker
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 683886 684345 (view as bug list)
Depends on:
Blocks: 681143
 
 
Reported: 2012-08-10 06:39 UTC by Olav Vitters
Modified: 2012-09-19 21:55 UTC
See Also:
GNOME target: 3.6
GNOME version: ---


Attachments
UnlockDialog: allow typing before the first question from PAM (2.04 KB, patch)
2012-08-13 16:42 UTC, Giovanni Campagna
none Details | Review
UnlockDialog: don't emit loaded until effectively loaded (1.11 KB, patch)
2012-08-13 16:42 UTC, Giovanni Campagna
none Details | Review
UnlockDialog: allow typing before the first question from PAM (3.64 KB, patch)
2012-09-13 21:45 UTC, Giovanni Campagna
committed Details | Review

Description Olav Vitters 2012-08-10 06:39:00 UTC
To repeat:
- Leave computer idle overnight
- Have cron run all kinds of intensive disk IO things
- Don't have an SSD, but go for a slow big disk
- Turn on monitor
- Press escape, then immediately start typing your password

Actual Results:
- For a few characters (2 or 3), I see the first few characters of my password and the disk is spinning like crazy
- After maybe 0.5 seconds, it changes the characters into a normal password entry

Expected results:
- Never showing my password!


I *cannot* repeat this by Lock the screen, so I'm guessing it is very timing related, or maybe I really have to wait for my system to be idle. I hope this can be fixed by looking at the code.
Comment 1 Olav Vitters 2012-08-11 01:53:51 UTC
I was able to reproduce it just now. Basically I start typing immediately after pressing escape. The password is shown while the screen moves upward. As soon as the upward movement stops, the password box is hidden / cleared.
Comment 2 Giovanni Campagna 2012-08-13 16:41:23 UTC
Ok, so the problem here is that we show the entry before we get the actual prompt from GDM (which in turn is slow because it has to spawn a process and bubble the various DBus message through several layers).

I see (and implemented) two solutions here:
- Don't show the dialog until it is completely ready
- Optimize for the common unix local password case, and make the entry do the right thing.

Both ways have their own problems, in particular:
- gdm is slow, so going with 1) breaks the illusion of a dialog always there behind the curtain, even if we start creating it on drag start or esc key press
- PAM is unpredictable, so going with 2) still has the "Password: " label fading in (as it could be anything, not just a password), and if you type fast enough you can finish the password with "Unlock" still insensitive - it has to be this way because we can't answer a query before we even get it

Up to the designers to choose which one they prefer. Personally I'd go with 1.
Comment 3 Giovanni Campagna 2012-08-13 16:42:04 UTC
Created attachment 221034 [details] [review]
UnlockDialog: allow typing before the first question from PAM

If the user starts typing right away, assume that the entry is
for a password and don't clear it when the secret request actually
comes.
Comment 4 Giovanni Campagna 2012-08-13 16:42:22 UTC
Created attachment 221035 [details] [review]
UnlockDialog: don't emit loaded until effectively loaded

Delay showing the dialog until the conversation with GDM has started.
This avoids showing an half prepared dialog, with the prompt fading
in. OTOH, with this and a lagging gdm, the dialog appears after
a while when pressing esc.
Comment 5 Matthias Clasen 2012-09-07 16:17:22 UTC
Can we get this reviewed ? Showing passwords in cleartext is kinda bad...
Comment 6 Jasper St. Pierre (not reading bugmail) 2012-09-07 17:15:30 UTC
(In reply to comment #2)
> - PAM is unpredictable, so going with 2) still has the "Password: " label
> fading in (as it could be anything, not just a password), and if you type fast
> enough you can finish the password with "Unlock" still insensitive - it has to
> be this way because we can't answer a query before we even get it

Could you queue up an answer to the query and submit it as soon as you get it?
Comment 7 Ray Strode [halfline] 2012-09-12 19:47:43 UTC
*** Bug 683886 has been marked as a duplicate of this bug. ***
Comment 8 Giovanni Campagna 2012-09-13 21:45:15 UTC
Created attachment 224283 [details] [review]
UnlockDialog: allow typing before the first question from PAM

If the user starts typing right away, assume that the entry is
for a password and don't clear it when the secret request actually
comes. Then, if the user completes typing, we also stash the answer
and send it to GDM right away on the first PAM prompt.

Ok, this allows clicking the first time. I'm less confident with
this one, there is a risk of passwords ending up as usernames in syslog,
but it's probably safe in common / known configurations, and that's where
muscle-memory kicks in and makes this most useful.
Comment 9 Jasper St. Pierre (not reading bugmail) 2012-09-14 16:36:58 UTC
Review of attachment 224283 [details] [review]:

This looks good.
Comment 10 Giovanni Campagna 2012-09-14 16:47:16 UTC
Attachment 224283 [details] pushed as 3d63202 - UnlockDialog: allow typing before the first question from PAM
Comment 11 Ray Strode [halfline] 2012-09-14 19:12:27 UTC
we should probably tyr to get this type ahead feature in the login dialog too.
Comment 12 Jasper St. Pierre (not reading bugmail) 2012-09-14 22:06:35 UTC
That makes sense. I wonder if it's better to have this login in the ShellUserVerifier.
Comment 13 drago01 2012-09-19 21:55:02 UTC
*** Bug 684345 has been marked as a duplicate of this bug. ***