I can’t see the greeter after login so I don’t know how I can debug it
Why the idea to fix “only for me” / for current usage scenario should be preferred over general vulnerability fix, not a single aspect of one case only?
To fix severe vulnerabilities only-for-me/for certain case/usage scenario is awful idea to implement. The git’s post suggests to do it in three places.
Because it’s temporary solution.
I personally don’t want to dive into sddm code and check how to run wayland on the same tty as sddm greeter.
1 Like
Fast mitigation. Got it. Agree. Thank you!
Well done for this one theme.
This should however be upstreamed so it’s available in general.
1 Like
If I understand this correct - in essense - it is not sddm itself - but the themes which should remove the password on succesful login.
It makes sense - at least from a developer perspective - as sddm is drawing the theme.
If the theme provides an option to show the password then sddm has no knowledge of the password being revealed - it then stands to reason the theme also removes the password on success.
The question is only if the fix work or not, as those who provide the fix can’t reproduce the issue at all on their machines. So it needs to. Be verified by the user who has the issue.
Also we should check if the change needs a recompile of the theme or if I this text and works on reboot.
1 Like
I also cannot see the greeter after login if I have my external monitor connected. Bu if I unplug it and then login using only my laptop’s display, then I see this issue.
1 Like
Well I don’t have a second monitor and also can’t see the greeter in a VM.
I tested this using sddm from git and changes suggested in the issue thread, also applied changes made by @LordTermor
Still this nasty bug present.
I quit using Breath2 theme until further ideas. Maldives and Breeze are quite pretty, too.
Not that I used Breath2 or its password reveal button or Wayland in general before, but anyway…
Found that I can see the greeter after login on my laptop. It might be some bug since in logs there’s a message that Greeter stopped in sddm logs. Anyway, I wrote more about one another solution on GitHub issue discussion.
Maybe it stops the greeter but forgets to clear the greeter’s state from the running Xorg server.
Did another effort: now password box is hidden during the login process and is shown back only on login failure. Will be updated soon. Hope will work for everyone who face this issue.
5 Likes
Hope this is not the theme-related fix: to let a theme decide to expose a password or not, but sddm itself for all themes / next dependencies.
But anyway, better to have at least any level fix in emergency timings.
1 Like
This can’t be a non-theme-related fix as it’s up to theme to decide to show password or not. SDDM only asks for username and password from greeter and doesn’t know about other things. Proper fix would require SDDM internals understanding which I don’t have.
It’s awful: anybody who will ship new theme or maintain any existed and still did not realize that, will immediately resurrects passwords leakage vulnerability. It should be sddm-related behavior only.
Nice to hear what we fix it as we currently can. Thank you!
1 Like
I can confirm my password is no longer shown on TTY1 with the updated sddm-breath2-theme. I hope SDDM developers will fix it that the greeter is cleared completely from TTY1 upon login.
unstable branch here.
Wow, got updates possibly related to the topic:
To upgrade (1):
manjaro-kde-settings 20211130-1 (20211128-1) community 13.9 kB
To install (2):
plasma5-themes-breath 21.2.0-0 (Replaces: plasma5-themes-breath2) community 26.8 MB
sddm-breath-theme 21.2.0-0 (Replaces: sddm-breath2-theme) community 129.9 kB
To remove (3):
sddm-breath2-theme 1.0.20-1 community
plasma5-themes-breath2 1.0.18-5 (Conflicts With: plasma5-themes-breath) community
breath2-icon-themes 1.0.18-5 (Conflicts With: plasma5-themes-breath) community
1 Like