[regression] Ubuntu 18.04 login screen rejects a valid password on first attempt (if starting with Shift key). Usually works on the second attempt

Bug #1765261 reported by Daniel van Vugt on 2018-04-19
150
This bug affects 26 people
Affects Status Importance Assigned to Milestone
gnome-shell (Fedora)
Fix Released
Medium
gnome-shell (Ubuntu)
High
Olivier Tilloy
Bionic
High
Olivier Tilloy

Bug Description

Upstream:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/240

Workaround:
Hit a lower-case key, then backspace, then enter your password.

Original description:
Ubuntu 18.04 login screen rejects a valid password on first attempt. Always works on the second attempt..

This seems to be a new problem, just started today.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gdm3 3.28.0-0ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-15.16-generic 4.15.15
Uname: Linux 4.15.0-15-generic x86_64
ApportVersion: 2.20.9-0ubuntu5
Architecture: amd64
Date: Thu Apr 19 11:16:17 2018
InstallationDate: Installed on 2017-12-12 (127 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171211)
SourcePackage: gdm3
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Created attachment 1423716
Journalctl log showing auth failure

Description of problem:
After every reboot the first login attempt fails. At first I assumed I was mistyping the password. Then I started slowly pressing one key at a time to confirm and it still failed. Same pass on all subsequent tries works, even after locking screen.

Version-Release number of selected component (if applicable):
gdm-3.28.1-1.fc28.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Reboot laptop
2. Select User
3. Enter Password
4. Hit Enter or Click button

Actual results:
Login fails on first try

Expected results:
Login succeeds when correct password is entered

Additional info:
This is an upgrade from Fedora 27

Daniel van Vugt (vanvugt) wrote :
Daniel van Vugt (vanvugt) wrote :

Seems related to a cold boot. Once it starts working, it keeps working.

Daniel van Vugt (vanvugt) wrote :

Possibly related: bug 1590719, bug 1720010

Daniel van Vugt (vanvugt) wrote :

Some extra info...

I have noticed that this does actually happen after I lock my screen as well.

I noticed one more possibly important fact. If I type characters (any number of characters) of the password in GDM login screen and then backspace to delete them all... then type in the password and press enter... it works.

So assume my password is 'MyPass!' (hypothetically), I type 'M' then backspace to delete that character then proceed to type 'MyPass!' it will then allow me to log in on the first attempt. Or... I type 'MyPass!' on first attempt (no backspace trick) and it fails... then type 'MyPass!' on second attempt... it works then too.

This seems very much like the first character is somehow entered wrong, but then just the act of deleting it and retyping it, or entering the password a second time it is entered correctly. Maybe libinput issue or similar?

Daniel van Vugt (vanvugt) wrote :

See also bug 1766137

EXAMPLE 1

/var/log/auth.log

LOGIN FAILED:
Apr 23 14:30:40 haz sudo: pam_unix(sudo:session): session opened for user root by dan(uid=0)
Apr 23 14:30:57 haz gdm-password]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=dan

LOGIN SUCCEEDED ON SECOND ATTEMPT:
Apr 23 14:31:23 haz gdm-password]: pam_unix(gdm-password:session): session opened for user dan by (uid=0)
Apr 23 14:31:23 haz systemd-logind[725]: New session 8 of user dan.

summary: Ubuntu 18.04 login screen rejects a valid password on first attempt.
- Always works on the second attempt
+ Usually works on the second attempt
Daniel van Vugt (vanvugt) wrote :

EXAMPLE 2

/var/log/auth.log

LOGIN FAILED:
Apr 23 14:33:34 haz gdm-password]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=dan

LOGIN ALMOST SUCCEEDED (but then hit bug 1766137):
Apr 23 14:33:46 haz gdm-password]: pam_unix(gdm-password:session): session opened for user dan by (uid=0)
--- there is no gnome-shell process running, but journalctl shows: ---
Apr 23 14:33:47 haz gnome-shell[912]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

Daniel van Vugt (vanvugt) wrote :

EXAMPLE 3

journalctl -b -f

LOGIN FAILED:
Apr 23 14:40:40 haz gdm-password][1342]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=dan
Apr 23 14:40:46 haz systemd[1]: Starting Stop ureadahead data collection...
Apr 23 14:40:46 haz systemd[1]: Started Stop ureadahead data collection.

LOGIN SUCCEEDED ON SECOND ATTEMPT:
Apr 23 14:41:12 haz gdm-password][1349]: pam_unix(gdm-password:session): session opened for user dan by (uid=0)
Apr 23 14:41:12 haz systemd-logind[818]: New session 4 of user dan.
Apr 23 14:41:12 haz systemd[1]: Started Session 4 of user dan.

Changed in gdm3 (Ubuntu):
importance: Undecided → High
Daniel van Vugt (vanvugt) wrote :
Download full text (3.8 KiB)

Here's the installation log from the day the regression happened (I think).

Start-Date: 2018-04-19 09:16:47
Commandline: apt full-upgrade
Requested-By: dan (1000)
Install: libisc169:amd64 (1:9.11.3+dfsg-1ubuntu1, automatic), libisc-export169:amd64 (1:9.11.3+dfsg-1ubuntu1, automatic), libsysmetrics1:amd64 (1.0.8, automatic), libdns-export1100:amd64 (1:9.11.3+dfsg-1ubuntu1, automatic), gnome-initial-setup:amd64 (3.28.0-2ubuntu3, automatic), libdns1100:amd64 (1:9.11.3+dfsg-1ubuntu1, automatic), ubuntu-report:amd64 (1.0.8, automatic)
Upgrade: ubuntu-settings:amd64 (18.04.4, 18.04.5), libgoa-backend-1.0-1:amd64 (3.28.0-0ubuntu1, 3.28.0-0ubuntu2), libgjs-dev:amd64 (1.52.1-1, 1.52.1-1ubuntu1), gnome-calendar:amd64 (3.28.1-1ubuntu1, 3.28.1-1ubuntu2), netplan.io:amd64 (0.34.1, 0.35), libibus-1.0-dev:amd64 (1.5.17-3ubuntu3, 1.5.17-3ubuntu4), libisccfg160:amd64 (1:9.11.2.P1-1ubuntu5, 1:9.11.3+dfsg-1ubuntu1), networkd-dispatcher:amd64 (1.7-0ubuntu1, 1.7-0ubuntu2), gir1.2-mutter-2:amd64 (3.28.0-2, 3.28.1-1), libgoa-1.0-0b:amd64 (3.28.0-0ubuntu1, 3.28.0-0ubuntu2), update-notifier-common:amd64 (3.190, 3.191), libgoa-1.0-common:amd64 (3.28.0-0ubuntu1, 3.28.0-0ubuntu2), libgjs0g:amd64 (1.52.1-1, 1.52.1-1ubuntu1), libirs160:amd64 (1:9.11.2.P1-1ubuntu5, 1:9.11.3+dfsg-1ubuntu1), bind9-host:amd64 (1:9.11.2.P1-1ubuntu5, 1:9.11.3+dfsg-1ubuntu1), dnsutils:amd64 (1:9.11.2.P1-1ubuntu5, 1:9.11.3+dfsg-1ubuntu1), ubuntu-standard:amd64 (1.416, 1.417), ubuntu-desktop:amd64 (1.416, 1.417), libmutter-2-0:amd64 (3.28.0-2, 3.28.1-1), libgoa-1.0-dev:amd64 (3.28.0-0ubuntu1, 3.28.0-0ubuntu2), gjs:amd64 (1.52.1-1, 1.52.1-1ubuntu1), libkeyutils-dev:amd64 (1.5.9-9.2ubuntu1, 1.5.9-9.2ubuntu2), isc-dhcp-common:amd64 (4.3.5-3ubuntu6, 4.3.5-3ubuntu7), command-not-found-data:amd64 (18.04.2, 18.04.3), gnumeric-doc:amd64 (1.12.35-1, 1.12.35-1.1), ibus-gtk:amd64 (1.5.17-3ubuntu3, 1.5.17-3ubuntu4), ibus-gtk3:amd64 (1.5.17-3ubuntu3, 1.5.17-3ubuntu4), gnumeric-common:amd64 (1.12.35-1, 1.12.35-1.1), mutter-common:amd64 (3.28.0-2, 3.28.1-1), nplan:amd64 (0.34.1, 0.35), ubuntu-minimal:amd64 (1.416, 1.417), python3-distupgrade:amd64 (1:18.04.16, 1:18.04.17), python3-commandnotfound:amd64 (18.04.2, 18.04.3), ubuntu-release-upgrader-core:amd64 (1:18.04.16, 1:18.04.17), libgoa-backend-1.0-dev:amd64 (3.28.0-0ubuntu1, 3.28.0-0ubuntu2), liblwres160:amd64 (1:9.11.2.P1-1ubuntu5, 1:9.11.3+dfsg-1ubuntu1), libkeyutils1:amd64 (1.5.9-9.2ubuntu1, 1.5.9-9.2ubuntu2), gnome-shell-common:amd64 (3.28.0-0ubuntu5, 3.28.1-0ubuntu1), gir1.2-goa-1.0:amd64 (3.28.0-0ubuntu1, 3.28.0-0ubuntu2), gnome-online-accounts:amd64 (3.28.0-0ubuntu1, 3.28.0-0ubuntu2), ibus:amd64 (1.5.17-3ubuntu3, 1.5.17-3ubuntu4), thermald:amd64 (1.7.0-3, 1.7.0-5), ubuntu-release-upgrader-gtk:amd64 (1:18.04.16, 1:18.04.17), mythes-en-us:amd64 (1:6.0.3-2, 1:6.0.3-3), libibus-1.0-5:amd64 (1.5.17-3ubuntu3, 1.5.17-3ubuntu4), gir1.2-ibus-1.0:amd64 (1.5.17-3ubuntu3, 1.5.17-3ubuntu4), command-not-found:amd64 (18.04.2, 18.04.3), libisccc160:amd64 (1:9.11.2.P1-1ubuntu5, 1:9.11.3+dfsg-1ubuntu1), gnome-shell:amd64 (3.28.0-0ubuntu5, 3.28.1-0ubuntu1), libbind9-160:amd64 (1:9.11.2.P1-1ubuntu5, 1:9.11.3+dfsg-1ubuntu1), ubuntu-web-launchers:amd64 (18.04.4, 18.04.5),...

Read more...

summary: - Ubuntu 18.04 login screen rejects a valid password on first attempt.
- Usually works on the second attempt
+ [regression] Ubuntu 18.04 login screen rejects a valid password on first
+ attempt. Usually works on the second attempt
tags: added: regression

The good news is that I'm not seeing this bug on most bionic machines. Only one desktop.

Daniel van Vugt (vanvugt) wrote :

The bug stopped happening today. Here's what changed:

Start-Date: 2018-04-24 09:15:49
Commandline: apt full-upgrade
Requested-By: dan (1000)
Install: linux-modules-extra-4.15.0-19-generic:amd64 (4.15.0-19.20, automatic), linux-modules-4.15.0-19-generic:amd64 (4.15.0-19.20, automatic), linux-headers-4.15.0-19-generic:amd64 (4.15.0-19.20, automatic), libfastjson4:amd64 (0.99.8-2, automatic), linux-headers-4.15.0-19:amd64 (4.15.0-19.20, automatic), linux-image-4.15.0-19-generic:amd64 (4.15.0-19.20, automatic)
Upgrade: speech-dispatcher-espeak-ng:amd64 (0.8.8-1, 0.8.8-1ubuntu1), speech-dispatcher-audio-plugins:amd64 (0.8.8-1, 0.8.8-1ubuntu1), netplan.io:amd64 (0.35, 0.36.1), language-pack-gnome-en:amd64 (1:18.04+20180419, 1:18.04+20180423), linux-headers-generic:amd64 (4.15.0.15.16, 4.15.0.19.20), linux-libc-dev:amd64 (4.15.0-15.16, 4.15.0-19.20), liblensfun1:amd64 (0.3.2-3, 0.3.2-4), libspeechd2:amd64 (0.8.8-1, 0.8.8-1ubuntu1), speech-dispatcher:amd64 (0.8.8-1, 0.8.8-1ubuntu1), libsystemd0:amd64 (237-3ubuntu8, 237-3ubuntu10), linux-image-generic:amd64 (4.15.0.15.16, 4.15.0.19.20), libsystemd-dev:amd64 (237-3ubuntu8, 237-3ubuntu10), linux-signed-image-generic:amd64 (4.15.0.15.16, 4.15.0.19.20), udev:amd64 (237-3ubuntu8, 237-3ubuntu10), language-pack-en:amd64 (1:18.04+20180419, 1:18.04+20180423), libmpdec2:amd64 (2.4.2-1, 2.4.2-1ubuntu1), linux-signed-generic:amd64 (4.15.0.15.16, 4.15.0.19.20), libudev1:amd64 (237-3ubuntu8, 237-3ubuntu10), rsyslog:amd64 (8.16.0-1ubuntu10, 8.32.0-1ubuntu3), libxshmfence1:amd64 (1.2-1, 1.3-1), nplan:amd64 (0.35, 0.36.1), python3-speechd:amd64 (0.8.8-1, 0.8.8-1ubuntu1), libudev-dev:amd64 (237-3ubuntu8, 237-3ubuntu10), libnss-myhostname:amd64 (237-3ubuntu8, 237-3ubuntu10), libxshmfence-dev:amd64 (1.2-1, 1.3-1), language-pack-gnome-en-base:amd64 (1:18.04+20180419, 1:18.04+20180423), systemd-sysv:amd64 (237-3ubuntu8, 237-3ubuntu10), liblensfun-data-v1:amd64 (0.3.2-3, 0.3.2-4), libpam-systemd:amd64 (237-3ubuntu8, 237-3ubuntu10), systemd:amd64 (237-3ubuntu8, 237-3ubuntu10), shim-signed:amd64 (1.33.1+13-0ubuntu2, 1.34.5+13-0ubuntu2), libnss-systemd:amd64 (237-3ubuntu8, 237-3ubuntu10), language-pack-en-base:amd64 (1:18.04+20180419, 1:18.04+20180423), linux-generic:amd64 (4.15.0.15.16, 4.15.0.19.20), libabw-0.1-1:amd64 (0.1.1-4ubuntu1, 0.1.2-1ubuntu1)
End-Date: 2018-04-24 09:18:31

Start-Date: 2018-04-24 11:18:57
Commandline: apt full-upgrade
Requested-By: dan (1000)
Upgrade: command-not-found-data:amd64 (18.04.3, 18.04.4), python3-commandnotfound:amd64 (18.04.3, 18.04.4), shim-signed:amd64 (1.34.5+13-0ubuntu2, 1.34.6+13-0ubuntu2), command-not-found:amd64 (18.04.3, 18.04.4)
End-Date: 2018-04-24 11:19:03

But also I switched monitors. I'm assuming that's not a factor...?

Changed in gdm3 (Ubuntu):
status: New → Incomplete

Same here on two different F28 systems.

Proposed as a Blocker for 28-final by Fedora user ddreggors using the blocker tracking app because:

 Fails basic functionality without user intervention. GDM cannot login on first attempt without trying a second time.

Haven't seen this in any of my F28 tests so far.

When you say "Select User", how do you do that exactly?

Also, what keyboard layout do you use?

After reboot there is a list of users. As I'm the only user I just press "enter" after which I'm asked to enter my password.

However, as the same issue also arises after locking the session, I don't think the user selection has anything to do with this.

I use a German keyboard layout.

Xavier Guillot (valeryan-24) wrote :

I have the same problem with Gnome-packagekit : first password attempt doesn't work (Authentification failure, try again), second is always successful.

I can't reproduce this. I tried regular en-US and upgraded from F27 to F28 without any issues. I have also checked it for root/created user across X and Wayland.

Changed in gdm3 (Ubuntu):
status: Incomplete → Confirmed

Can't reproduce with installation updated from F27 and German keyboard layout.

David, Thomas, this is just a wild guess, but can you try the workaround mentioned in here?
https://fedoraproject.org/wiki/Common_F27_bugs#every-second-login-fails

I.e. try to use X11 session instead of Wayland session, and see if "auto-save-session" value is true or not. Thanks.

Well I have somewhat similar thing to report here. Since I upgraded to Fedora 28, whenever screen gets locked out and I return back to unlock it, my first attempt after entering correct password fails (I kept blaming myself for wrong developed muscle memory) but after seeing this bug, I thought to report here.

This is consistent for me. The first attempt to unlock screen failed most times(may be I can say it always failed). But second attempt always succeeds.

I also already have gsettings get org.gnome.SessionManager auto-save-session -> false.

Can't reproduce this on any of my F28 systems.

I cannot reproduce this either.

I'm inclined to vote -1 blocker on the following grounds:
1) Once this is identified, it can be resolved with an update
2) Most users would default to assuming they'd mistyped the first time and re-enter their password.

-1 blocker for reasons Stephen notes (along with "can't reproduce" comments).

Those who experience the bug, can you right click on the password field and click "Show Text" (or whatever it is in your language) after entering the password for the first time to see if that matches what you're typing?

(In reply to J. Haas from comment #15)
> Those who experience the bug, can you right click on the password field and
> click "Show Text" (or whatever it is in your language) after entering the
> password for the first time to see if that matches what you're typing?

Interesting... it appears to ignore the shift-key, i.e. a small letter is always entered.

Theory: Everybody who was not able to reproduce this uses a small letter at the beginning of his/her password?

(In reply to Thomas Müller from comment #16)
> (In reply to J. Haas from comment #15)
> > Those who experience the bug, can you right click on the password field and
> > click "Show Text" (or whatever it is in your language) after entering the
> > password for the first time to see if that matches what you're typing?
>
> Interesting... it appears to ignore the shift-key, i.e. a small letter is
> always entered.
>
> Theory: Everybody who was not able to reproduce this uses a small letter at
> the beginning of his/her password?

I can actually now reproduce this (and yes, the shift is initially ignored) when attempting to enter a password for my GPG key using the GNOME askpass dialog (starts with a capital letter).

So I'd say the above theory seems likely. That's... quite a catch.

I'm still -1 blocker on it for the reasons above, but we should try to fix this as quickly as possible.

Are there any use cases where the askpass dialog is also used to set a *new* password somewhere?
If yes and the same behavior applies there users are going to be frustrated if they can't use their password later on as the first letter is not what they would expect it to be.

Thanks J. Haas, I also confirm its an issue with shift key. It ignores shift-key usage at the first time and if I backspace before completing password and retype my password, it works.

I still can't reproduce this in a fresh install to a VM, FWIW. I installed from the RC-1.1 Workstation live, created user Test with password Test in gnome-initial-setup on first boot, and was able to log in first time both on the initial appearance of GDM after g-i-s was complete, and after a reboot. The 'show text' option shows that I truly did type 'Test'.

Stephen, how did you reproduce this exactly?

Oh, I *can* reproduce the case for the lock screen, though. Dunno why I see that one but not the GDM one.

(In reply to Adam Williamson from comment #21)
> Oh, I *can* reproduce the case for the lock screen, though. Dunno why I see
> that one but not the GDM one.

Yeah, I was about to say that: I can repro it on lock screen and askpass, but I didn't see it happen at GDM. Not sure why.

My running hypothesis is that we inherited this with the gtk3 rebase we pulled in for FE, since I am pretty sure I didn't see it before I updated yesterday (and I have had the -testing repos disabled since we entered Freeze).

"Are there any use cases where the askpass dialog is also used to set a *new* password somewhere?"

The only case I can think of where it might happen is timed password expiry, we could test that.

-1 blocker, this can be fixed post-release

(In reply to Adam Williamson from comment #23)
> "Are there any use cases where the askpass dialog is also used to set a
> *new* password somewhere?"
>
> The only case I can think of where it might happen is timed password expiry,
> we could test that.

Adam: I think this would already be covered by automated testing for https://fedoraproject.org/wiki/QA:Testcase_FreeIPA_password_change or am I mistaken?

I'm definitely reconsidering my -1. If we can verify that it's just the first attempt and just the lockscreen/askpass, a zero-day would probably be okay.

I'll weight Michael Catanzaro and other Workstation team members' opinions on this heavily — if they're not going to be embarrassed, I'll try not to be. :)

I can verify that this also happens in the "create keyring" dialog in Seahorse when setting a password for the keyring. It's not a huge problem, as you need to enter the password twice and the problem only happens in the topmost password box, but it's definitely annoying.

I've actually seen this about a year ago.

I had upgraded from Fedora Workstation 26 to 27. I don't remember whether this happened to me before the upgrade, but it certainly happened after.

I remember that it was happening a bit before GUADEC, so I'd figure I'd try and find someone there to fix it.

It stopped happening right before GUADEC, when I reinstalled my machine. (the day I was supposed to take the plane, I run an unfortunate `rm -rf /` and had to reinstall and restore my data from backup)

So I guess this isn't a recent regression, but something old which just doesn't happen for most people?

(In reply to Matthew Miller from comment #26)
> I'm definitely reconsidering my -1. If we can verify that it's just the
> first attempt and just the lockscreen/askpass, a zero-day would probably be
> okay.
>
> I'll weight Michael Catanzaro and other Workstation team members' opinions
> on this heavily — if they're not going to be embarrassed, I'll try not to
> be. :)

I think we should try to fix it ASAP, of course. But if we have a zero-day update, then users will hopefully only hit this bug once or twice at most, in which case they probably won't even notice.

(In reply to J. Haas from comment #27)
> I can verify that this also happens in the "create keyring" dialog in
> Seahorse when setting a password for the keyring. It's not a huge problem,
> as you need to enter the password twice and the problem only happens in the
> topmost password box, but it's definitely annoying.

OK, that changes everything. I have two thoughts on this:

 (a) Most of seahorse is already super broken and has been for a long time, that's why we don't install it anymore
 (b) That's a GTK+ dialog

(b) is very significant because up until now, all the reported password entries were gnome-shell: that's why I reassigned the bug to gnome-shell. Now you're saying this affects GTK+ as well, right? I just tested with seahorse, and the password entry was a normal GTK+ dialog drawn by seahorse itself, not the black overlay that gnome-shell draws when it asks for your password? That's *really* seriously weird; it's hard to imagine what could break password entry in two unrelated toolkits. Maybe ibus?

(In reply to Michael Catanzaro from comment #29)
> (a) Most of seahorse is already super broken and has been for a long time,
> that's why we don't install it anymore

(BTW please keep this in mind: seahorse is no longer on the live image. We actually had a presentation at GUADEC a couple years ago that was all about how almost all of the menu items and dialogs were broken. Please don't consider seahorse at all when making a blocker determination.)

Created attachment 1427284
Seahorse screenshot

I'm not sure Seahorse uses a GTK+ dialog, it draws the black shadow and so on.

Here I entered "Test" in both password boxes, but it ignored the first shift key press.

(In reply to Michael Catanzaro from comment #29)
> (In reply to Matthew Miller from comment #26)
> > I'm definitely reconsidering my -1. If we can verify that it's just the
> > first attempt and just the lockscreen/askpass, a zero-day would probably be
> > okay.
> >
> > I'll weight Michael Catanzaro and other Workstation team members' opinions
> > on this heavily — if they're not going to be embarrassed, I'll try not to
> > be. :)
>
> I think we should try to fix it ASAP, of course. But if we have a zero-day
> update, then users will hopefully only hit this bug once or twice at most,
> in which case they probably won't even notice.
>
> (In reply to J. Haas from comment #27)
> > I can verify that this also happens in the "create keyring" dialog in
> > Seahorse when setting a password for the keyring. It's not a huge problem,
> > as you need to enter the password twice and the problem only happens in the
> > topmost password box, but it's definitely annoying.
>
> OK, that changes everything. I have two thoughts on this:
>
> (a) Most of seahorse is already super broken and has been for a long time,
> that's why we don't install it anymore
> (b) That's a GTK+ dialog
>
> (b) is very significant because up until now, all the reported password
> entries were gnome-shell: that's why I reassigned the bug to gnome-shell.
> Now you're saying this affects GTK+ as well, right? I just tested with
> seahorse, and the password entry was a normal GTK+ dialog drawn by seahorse
> itself, not the black overlay that gnome-shell draws when it asks for your
> password? That's *really* seriously weird; it's hard to imagine what could
> break password entry in two unrelated toolkits. Maybe ibus?

I just tested this and it is NOT using the GTK+ dialog, it's using the GNOME Shell dialog. I'm not sure when that changed, but I hope that information is less alarming.

(In reply to J. Haas from comment #31)
> Created attachment 1427284 [details]
> Seahorse screenshot
>
> I'm not sure Seahorse uses a GTK+ dialog, it draws the black shadow and so
> on.
>
> Here I entered "Test" in both password boxes, but it ignored the first shift
> key press.

Yeah, that's the gnome-shell prompt. OK, less alarming indeed.

Well, still bad, but more understandable.

You actually kinda can reproduce this outside of gnome-shell password prompts. If you manage to exit a gnome-shell password prompt while a standard GTK textfield already is focused, and then you try to directly type uppercase text, it will ignore the shift key press.

You can easily reproduce that with the Seahorse dialog I took a screenshot of, but I also managed to reproduce it with a password prompt in Nautilus.

This also appears to affect the "unlock" dialog in Gnome Control Panel, for what it's worth.

(In reply to Adam Williamson from comment #6)
> Also, what keyboard layout do you use?

Sorry I just saw this, I use English (US) keyboard layout. Also, by select user I meant on GDM login screen where you see your user (or others if they exist), I click myself if not already highlighted.

I added this info late I know, it seems there has been much movement on this bug and much has been discovered. Again, sorry for late reply.

(In reply to Thomas Müller from comment #16)
> (In reply to J. Haas from comment #15)
> > Those who experience the bug, can you right click on the password field and
> > click "Show Text" (or whatever it is in your language) after entering the
> > password for the first time to see if that matches what you're typing?
>
> Interesting... it appears to ignore the shift-key, i.e. a small letter is
> always entered.
>
> Theory: Everybody who was not able to reproduce this uses a small letter at
> the beginning of his/her password?

To confirm, I do use a capital letter as first character.

I would like to also remind all here that I was able to backspace after typing first character on first login attempt, then retype it and the shift key works (capital letter is entered this time).

This also affects other modifiers - I've just realized, because it affects pasting passwords into the password prompt :( This will affect everyone who uses a password manager, when they go to enter e.g. an ssh key via the ssh-askpass integration. Hitting 'ctrl-v' just gives you a 'v'. Just like with the 'shift' case, hitting backspace and then ctrl-v again works, or it works on the second attempt.

I cannot reproduce the problem.
Did you install the latest mutter & gnome-shell?

Lots of people have reproduced this so far, I don't think it's plausible to claim that the bug doesn't exist at this point. Yes, everyone is testing with the latest gnome-shell and mutter, in fact we think 3.28.1 actually *introduced* this bug. Multiple GNOME devs have already reproduced this and are discussing how to fix it, e.g. in this log from #fedora-desktop:

<garnacho> https://gitlab.gnome.org/GNOME/mutter/merge_requests/97 is for the password thing btw, root cause pending, but that's enough to fix it
<halfline> garnacho: nice
<halfline> hmm
<halfline> so that code got added here it seems: https://bugzilla.gnome.org/show_bug.cgi?id=725102
<halfline> and in that bug it says this: "switching the keymap
<halfline> should be done at a time when no key is currently pressed down, but let's leave that task to higher level code"
<garnacho> yeah, quite fishy that it changes while typing stuff, it's clearly not due to the focus change
<halfline> it's the same keymap again ?
<garnacho> in essence yes
<garnacho> maybe some explicit keymap change to cater for per-window IM -> clutter focus changes?
<garnacho> I guess that mention in the code is there for the situations where you shuffle modifier keys around
<garnacho> but hardly stands true with <super>space :/
<garnacho> s/in the code/in the bug/
<halfline> well your patch makes sense to me on the surface. i wish rtcm was here
<halfline> i wonder if it's from InputSourceManager's _keyboardOptionsChanged or from activateInputSource
<halfline> i guess if activating the input source is async and it happens on focus in that might explain it
* halfline tries adding some logs
<garnacho> halfline: not sure it's simply that. I've been trying with a polkit dialog, and took my time before typing
<garnacho> it's somehow sent around the same time shift is pressed
<garnacho> but yeah, ideally the keymap shouldn't even change :)
<halfline1> i was working on adding some backtrace dumpping to InputSource activate but had to run to a meeting

Marc Fouquet (marcf-launchpad) wrote :

After the first (failed) login, I get a purple screen with only the mouse pointer. In Syslog I found this:

Apr 28 10:28:05 xxxxxxxx systemd[1]: Started User Manager for UID 1000.
Apr 28 10:28:06 xxxxxxxx gnome-shell[987]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Apr 28 10:28:16 xxxxxxxx pulseaudio[15339]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the re
ply, the reply timeout expired, or the network connection was broken.
Apr 28 10:28:28 xxxxxxxx gnome-shell[987]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Apr 28 10:28:30 xxxxxxxx gdm3: GdmSession: conversation gdm-password started more than once
Apr 28 10:28:30 xxxxxxxx gnome-shell[987]: JS ERROR: Failed to start verification for user: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.Spawn.Failed: Hilfsprozess zur Legitimierung konnte nicht erstellt werden#012_startService/<@resource:///org/gnome/shell/gdm/util.j
s:436:20
Apr 28 10:28:33 xxxxxxxx gnome-shell[987]: g_dbus_connection_signal_unsubscribe: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Apr 28 10:28:33 xxxxxxxx gnome-shell[987]: g_dbus_connection_signal_unsubscribe: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Apr 28 10:28:33 xxxxxxxx gnome-shell[987]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Apr 28 10:28:46 xxxxxxxx systemd[1]: Started Session 27 of user xxxxxxxx.
Apr 28 10:28:46 xxxxxxxx gnome-shell[987]: g_dbus_connection_signal_unsubscribe: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Apr 28 10:28:46 xxxxxxxx gnome-shell[987]: g_dbus_connection_signal_unsubscribe: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Apr 28 10:28:46 xxxxxxxx gnome-shell[987]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(In reply to Adam Williamson from comment #40)
> Lots of people have reproduced this so far, I don't think it's plausible to
> claim that the bug doesn't exist at this point. Yes, everyone is testing
> with the latest gnome-shell and mutter, in fact we think 3.28.1 actually
> *introduced* this bug.

FWIW, 3.28.1 *re*introduced this bug, because 3.28.0 had other bug that prevented this in the first place on the most common setups. This seems to stem in untimely changes to the org.gnome.desktop.input-sources.sources dconf key that reset current modifier state.

My wild guess is that those actually come from ibus, but gnome-shell can protect itself from those, I opened https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/91 about it.

gnome-shell-3.28.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f1989df398

I backported the fix to Rawhide and F28 and submitted an update for F28. Thanks, Carlos. Can folks affected by this test and see if the update fixes it for you? Thanks!

Daniel van Vugt (vanvugt) wrote :
Changed in gdm3 (Ubuntu):
status: Confirmed → Triaged
description: updated
tags: added: fixed-in-3.28.2 fixed-in-3.29.2
Changed in gdm3 (Ubuntu):
assignee: nobody → Jeremy Bicha (jbicha)
affects: gdm3 (Ubuntu) → gnome-shell (Ubuntu)
Changed in gnome-shell (Ubuntu):
status: Triaged → In Progress
Changed in gnome-shell (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Committed

So far gnome-shell-3.28.1-3.fc28 is looking good. :)

This does not yet appear in updates-testing, should it?

(In reply to David Dreggors from comment #45)
> This does not yet appear in updates-testing, should it?

Not yet. There will be an automated comment on this bug when it reaches testing.

In the meantime you can download it direct from Koji for testing, the update page has a link through to the Koji build - https://koji.fedoraproject.org/koji/buildinfo?buildID=1077605

Discussed during F28 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-04-26/f28-final-go-no-go-meeting.2018-04-26-17.02.txt . It was generally felt that, while this is clearly a serious bug, it's not actually going to significantly inconvenience people during install boot and install of Workstation: even if they hit it they'll likely just assume they mis-typed, and type their password again, and it will work. Beyond that, it can be fixed with an update. Thus, this was rejected as a blocker.

gnome-shell-3.28.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f1989df398

gnome-shell-3.28.1-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Changed in gnome-shell (Fedora):
status: Fix Committed → Fix Released
Will Cooke (willcooke) on 2018-05-10
tags: added: unlock

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-shell (Ubuntu Bionic):
status: New → Confirmed
David Oxland (doxland) wrote :

Confirmed by me on 2018-05-11
18.04 Fresh install on 2018-05-05
INTEL NUC BOX7I7BNH
Symptoms the same; re signin.
After a couple of restarts and tries I out-waited it and home screen appeared.
Took 15 min.
Looks normal now

I am still seeing this or a related bug. With gnome-shell 3.28.1-3.fc28 installed, every text I type is using the english (US) keyboard layout in gdm, no matter what keyboard layout I configured. Switching the layout at runtime does not change anything. I have 3 layouts configured (de: neo, de: nodeadkeys, us). GDM always uses the last one no matter which one I configure.

On any tty and within any Gnome session, keyboard layouts behave correctly, using the default de:neo keyboard layout.

This looks like bug #1573923 to me.

(In reply to Christian Stadelmann from comment #51)
> This looks like bug #1573923 to me.

I think the fix for this bug introduced that one.

I confirm the bug on Ubuntu 18.04 + Gnome-Shell

It appears only after a locked screen, not at startup.
When I type my password to unlock, the first time always fails.
The second it OK.

If I type any character, then delete all with backspace and retype the password, it is OK at the first time.
It seems as it has an invisible character by default.

Vadim Peretokin (vperetokin) wrote :

Second time does not work for me - neither the third, nor the tenth. Once I lock the screen, there is a chance the GNOME environment will reject all password attempts to lock it and I have to lose all my work by forcing a restart. This is a very serious problem.

Is there a workaround available?

This bug exists in all password prompts throughout the GUI for me: login, VPN, and gpg (running gnome-session under Wayland). Sometimes they work on the first attempt, sometimes it takes 10 tries.

Daniel van Vugt (vanvugt) wrote :

Vadim, you might be experiencing a different bug but best to wait and see if that's true after a fix is released here.

I was hoping we would get the fix as part of Gnome 3.28.2 but I don't see that coming yet.

tsis (tsistemas) wrote :

hello all

Is there any flavor where this serious problem does not occur?

regards

Daniel van Vugt (vanvugt) wrote :

The bug is in gnome-shell, so anything other than that :)

tsis (tsistemas) wrote :

and what flavor of ubuntu do you recommend me with less bugs like this

thanks

Vadim Peretokin (vperetokin) wrote :

Sorry but this bug report is not for discussion on the best flavour of Ubuntu - please ask on the forums and don't spam everyone involved in the discussion.

Yes. If you choose "Show Text" in the right-click menu, it shows that the first letter was entered as a lowercase letter.

I've just noticed an interesting quirk to this bug; the Caps Lock modifier key does work for the first character on the first attempt.

That is to say open login screen (by space bar if not already open), press and release Caps Lock, Caps Lock light now on, very first character to be typed is now modified to upper case. Caps Lock may then be turned off.

I wondered why this one modifier does work, and thought that the modifier key being released before typing the character to be modified might be significant. So I tried pressing and releasing the normal shift key before pressing and holding it to modify the first character of the password. This also worked for me. (It is a little fiddly, so perhaps others might like to try to confirm that I'm not mistaken?)

So, at the login screen, with the password box open but nothing typed yet, press and release the (right in my test) shift key, then press and hold that shift key while typing the first character of the password. I believe that this will give correct modifier action for the shift key.

Daniel van Vugt (vanvugt) wrote :

It sounds like that's expected. The fix and upstream bug report mention the problem is specific to the Shift key:

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/91
https://gitlab.gnome.org/GNOME/gnome-shell/issues/240

Iain Lane (laney) on 2018-05-24
Changed in gnome-shell (Ubuntu Bionic):
assignee: nobody → Jeremy Bicha (jbicha)
Kabeer Vohra (kabeersvohra) wrote :

Can also confirm bug, when logging in from a reboot, it works fine but when I show text after locking and unlocking (using windows key + L to lock) and I show text, it seems that the first 3 letters of my password are lowercase even though I was holding shift. I can also confirm that backspacing them all (using ctrl + backspace) and retyping the password without attempting to log in with the incorrect password works fine.

I am using Gnome 3 on Ubuntu 18.04

Daniel van Vugt (vanvugt) wrote :

Oops. We have mutter 3.28.2 now, but not gnome-shell 3.28.2 yet.

Changed in gnome-shell (Ubuntu):
assignee: Jeremy Bicha (jbicha) → nobody
status: In Progress → Fix Released
status: Fix Released → Triaged
Changed in gnome-shell (Ubuntu Bionic):
assignee: Jeremy Bicha (jbicha) → nobody
importance: Undecided → High
status: Confirmed → Triaged
tags: added: rls-bb-incoming
summary: [regression] Ubuntu 18.04 login screen rejects a valid password on first
- attempt. Usually works on the second attempt
+ attempt (if starting with Shift key). Usually works on the second
+ attempt
description: updated
Didier Roche (didrocks) on 2018-06-05
Changed in gnome-shell (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
Changed in gnome-shell (Ubuntu Bionic):
assignee: nobody → Didier Roche (didrocks)
Olivier Tilloy (osomon) on 2018-06-05
Changed in gnome-shell (Ubuntu):
assignee: Didier Roche (didrocks) → Olivier Tilloy (osomon)
Changed in gnome-shell (Ubuntu Bionic):
assignee: Didier Roche (didrocks) → Olivier Tilloy (osomon)
Gabriel Bernard (leerro) wrote :

I can confirm having the same issue on my Ubuntu 18.04 system when using Wayland, but if I use a Xorg session the shift key is recognized and I have no issues.

Xylar Asay-Davis (xylarstorm) wrote :

I am experiencing the same issue as Vadim Peretokin above. I would agree that it appears to be a separate issue from the one discussed here -- it seems to have nothing to do with miscapitalization of the password (as revealed by "Show Text"). I have rarely experienced the issue at the first login screen but quite often at the lock screen. The only solution I have found is to reboot the machine (sometimes multiple times). I would prefer not to clutter up this discussion with an unrelated bug and can post a separate report but wanted see first if there was consensus that Vadim's and my issue sounds unrelated to the bug in this report.

Xylar Asay-Davis (xylarstorm) wrote :

I should have said that I am running Ubuntu 18.04 on a Dell XPS-13 9350, in case that is helpful.

tags: removed: rls-bb-incoming
Changed in gnome-shell (Ubuntu Bionic):
milestone: none → ubuntu-18.04.1
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-shell - 3.28.2-0ubuntu1

---------------
gnome-shell (3.28.2-0ubuntu1) cosmic; urgency=medium

  [ Olivier Tilloy ]
  * New upstream release
    - fixes valid password rejection at login screen (LP: #1765261)
  * Drop patches applied upstream:
    - debian/patches/polkitAgent-Guard-against-repeated-close-calls.patch
    - debian/patches/popupMenu-Fix-wrong-call-to-clutter_actor_add_child.patch
    - debian/patches/workspaceThumbnail-initialize-porthole-based-on-workArea.patch
    - debian/patches/workspaceThumbnail-only-update-_porthole-if-the-overview-.patch
    - debian/patches/workspaceThumbnail-rebuild-thumbnails-if-workareas-size-c.patch

  [ Andrea Azzarone ]
  * debian/patches/ubuntu_lock_on_suspend.patch: inhibit suspend until the
    screen is locked also in the case where automatic screen lock is disabled
    and screen lock on suspend is enabled (LP: #1768786)

  [ Marco Trevisan (Treviño) ]
  * Cherry pick upstream patches:
    - debian/patches/st-label-Unset-clutter-text-instance-on-disposal.patch (LP: #1714989)
  * debian/patches/st-texture-cache-Don-t-add-NULL-textures-to-cache.patch:
    - Cherry pick updated version from upstream, splitted in:
    + debian/patches/st-texture-cache-Don-t-add-NULL-textures-to-cache.patch
    + debian/patches/st-texture-cache-Save-cairo-surfaces-to-a-different-map.patch
  * debian/patches/authPrompt-Do-not-enable-sensitivity-if-retries-are-disal.patch
    debian/patches/authPrompt-Unset-preemptiveAnswer-on-reset.patch
    debian/patches/gdm-util-Always-allow-to-retry-login-in-unlock-mode.patch:
    - GDM gnome-shell greeter fix to fix unneeded login attempts (LP: #1777956)
  * debian/patches/series:
    - reorder to apply upstream cherry-picks before the others

  [ Daniel van Vugt ]
  * debian/patches/magnifier.js-Fix-zoom-juddering.patch:
    - magnifier.js: Fix zoom juddering (LP: #1691675)

 -- Marco Trevisan (Treviño) <email address hidden> Thu, 21 Jun 2018 01:59:11 +0200

Changed in gnome-shell (Ubuntu):
status: Triaged → Fix Released
Brian Murray (brian-murray) wrote :

This SRU bug report is missing a Test Case and a statement regarding the Regression Potential. While I'm accepting the SRU now, please get those added.

Changed in gnome-shell (Ubuntu Bionic):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-bionic

Hello Daniel, or anyone else affected,

Accepted gnome-shell into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnome-shell/3.28.2-0ubuntu0.18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Daniel van Vugt (vanvugt) wrote :

Verified. This bug is fixed in 3.28.2-0ubuntu0.18.04.1

tags: added: verification-done-bionic
removed: verification-needed-bionic
JoelS (joel-sewing) wrote :

Verified. This bug is fixed in 3.28.2-0ubuntu0.18.04.1

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-shell - 3.28.2-0ubuntu0.18.04.1

---------------
gnome-shell (3.28.2-0ubuntu0.18.04.1) bionic; urgency=medium

  [ Olivier Tilloy ]
  * New upstream release (LP: #1775145)
    - fixes valid password rejection at login screen (LP: #1765261)
  * Drop patches applied upstream:
    - debian/patches/polkitAgent-Guard-against-repeated-close-calls.patch
    - debian/patches/popupMenu-Fix-wrong-call-to-clutter_actor_add_child.patch
    - debian/patches/workspaceThumbnail-initialize-porthole-based-on-workArea.patch
    - debian/patches/workspaceThumbnail-only-update-_porthole-if-the-overview-.patch
    - debian/patches/workspaceThumbnail-rebuild-thumbnails-if-workareas-size-c.patch

  [ Andrea Azzarone ]
  * debian/patches/ubuntu_lock_on_suspend.patch: inhibit suspend until the
    screen is locked also in the case where automatic screen lock is disabled
    and screen lock on suspend is enabled (LP: #1768786)

  [ Marco Trevisan (Treviño) ]
  * Cherry pick upstream patches:
    - debian/patches/st-label-Unset-clutter-text-instance-on-disposal.patch (LP: #1714989)
  * debian/patches/st-texture-cache-Don-t-add-NULL-textures-to-cache.patch:
    - Cherry pick updated version from upstream, splitted in:
    + debian/patches/st-texture-cache-Don-t-add-NULL-textures-to-cache.patch
    + debian/patches/st-texture-cache-Save-cairo-surfaces-to-a-different-map.patch
  * debian/patches/authPrompt-Do-not-enable-sensitivity-if-retries-are-disal.patch
    debian/patches/authPrompt-Unset-preemptiveAnswer-on-reset.patch
    debian/patches/gdm-util-Always-allow-to-retry-login-in-unlock-mode.patch:
    - GDM gnome-shell greeter fix to fix unneeded login attempts (LP: #1777956)
  * debian/patches/series:
    - reorder to apply upstream cherry-picks before the others

  [ Daniel van Vugt ]
  * debian/patches/magnifier.js-Fix-zoom-juddering.patch:
    - magnifier.js: Fix zoom juddering (LP: #1691675)

 -- Marco Trevisan <email address hidden> Tue, 21 Jun 2018 01:45:42 +0200

Changed in gnome-shell (Ubuntu Bionic):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for gnome-shell has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.