RedHat has issued an advisory on August 1: https://access.redhat.com/errata/RHSA-2017:2128 Patched package uploaded for Mageia 5. Advisory: ======================== Updated gdm packages fix security vulnerability: It was found that gdm could crash due to a signal handler dispatched to an invalid conversation. An attacker could crash gdm by holding the escape key when the screen is locked, possibly bypassing the locked screen (CVE-2015-7496). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7496 https://access.redhat.com/errata/RHSA-2017:2128 ======================== Updated packages in core/updates_testing: ======================== gdm-3.14.2-5.1.mga5 libgdm1-3.14.2-5.1.mga5 libgdm-gir1.0-3.14.2-5.1.mga5 libgdm-devel-3.14.2-5.1.mga5 from gdm-3.14.2-5.1.mga5.src.rpm
mga5 x86_64 Mate Switched to gdm and tested login. Installed updates and restarted the desktop manager. Greeter window was complete - logged in again OK. $ rpm -qa | grep gdm lib64gdm-devel-3.14.2-5.1.mga5 gdm-3.14.2-5.1.mga5 lib64gdm-gir1.0-3.14.2-5.1.mga5 lib64gdm1-3.14.2-5.1.mga5
CC: (none) => tarazed25Whiteboard: (none) => MGA5-64-OK
mga5.1 i586 in virtualbox Installed the updates under Mate. Switched to gdm and logged in to KDE4. Tried successive logins for Xfce, Cinnamon, GNOME* and then Mate. The only one which presented a problem was GNOME on Wayland. That went straight back to the login prompt so perhaps Wayland means nothing in virtual machine. After that try the vm had to be reset before gdm would work properly again. Tested the other functions on the login screen - audio volume, screen brightness, restart and shutdown. All good. Holding back the OK pending real hardware checks.
Tests on real hardware, x86_64, demonstrate that there is a real problem with GNOME on Wayland. The GDM fault recurred. Suspecting that the GNOME installation was incomplete (task-gnome-minimal) I installed task-gnome and tried again but that did not help. On selection of the Wayland server the login prompt reappears and if any other DE is selected the window blanks the the user is dropped down to a console where the "good luck" message appears. So just selecting Wayland somehow upsets the X server. Maybe some link is being overwritten?? Anyway, we cannot release this without some clarification. Adding the feedback marker.
Whiteboard: MGA5-64-OK => MGA5-64-OK feedback
We probably need some debug info when the console comes up. Going back in.
GNOME on Wayland is a Mageia 6 thing (maybe available as a tech preview in Mageia 5 but certainly not supported), and nothing has been said about it being a regression, furthermore it has nothing to do with what this update is about.
Whiteboard: MGA5-64-OK feedback => MGA5-64-OK
So, you are saying that we should bypass the Wayland login. Fair enough. I was just trying to be thorough and test all the options - did not realize how experimental it is or that the failure is irrelevant. That is something which shall always be difficult to judge for simple-minded QA testers, which is a good reason to have the feedback marker. "nothing has been said about it being a regression" What is "it" and where is the implication of a regression? I don't follow. Nothing else fails so gdm passes on both architectures. And thanks for the clarification.
Whiteboard: MGA5-64-OK => MGA5-64-OK MGA5-64-OK
Whiteboard: MGA5-64-OK MGA5-64-OK => MGA5-64-OK MGA5-32-OK
Len, let me try to clear this up for you and hopefully make things easier for you going forward. This update was just the addition of a patch to address a specific issue detailed in the advisory. All that needs to be tested in a case like that is that issue, if possible. If not, just some general testing to make sure the thing isn't obviously broken would be sufficient (in this case, that'd mean testing that the lock screen still generally works). Usually it's only in the case of a version update with more significant changes do we need more thorough testing. As for the issue you found, sometimes we do turn up unrelated issues in QA testing, but that's usually in little-used packages where it just hadn't been noticed before. Then it's worth asking about to see if we want to fix it too. Something heavily used like gdm, something like that's unlikely to be an unknown issue. As to whether an issue would hold up an update, it only necessarily would if it was a regression caused by the update. So, when an issue like that is found, the first thing that should be determined is whether it is a regression. Thanks for all you continue to do. You're doing a great job.
Thanks for the extra clarification David. And it is true, I did not think of testing the screenlock (probably because it is something I have never set deliberately - had to find out how to do it). It does still work anyway.
Great, thanks. GDM is really weird. It somehow controls not only the login screen, but also the lock screen in GNOME.
The cat on the keyboard experiment did not do any harm either before or after the updates. Holding down the Esc key while the screen was locked made the screen flash for a while. There seemed to be a timeout on that. The flashing stopped and the Xscreensaver unlock dialogue came back and remained steady.
Advisory uploaded, validating.
Whiteboard: MGA5-64-OK MGA5-32-OK => advisory MGA5-64-OK MGA5-32-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0248.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED