| Summary: | Password typed during grace period is passed through to the foreground app, and can become visible | ||
|---|---|---|---|
| Product: | [Unmaintained] kscreenlocker | Reporter: | rugk <7429c5c9> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | bshah, jr, kde, kdebugs.81do7, nate, neon-bugs-null, sitter |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
rugk
2018-11-15 08:07:01 UTC
I don't understand. After #2, you should be looking at the lock screen. Text entered in the lock screen should stay on the lock screen. Are you saying that after the screen unlocks, your password has been entered into a text editor? Yes, the screen unlocks and this is expected. Because maybe I missed to say you have to be fast and enter the text directly after a few seconds after screen lock. Because the screen lock is so "soft" when locking automatically after the first few seconds, so you can still move the mouse or press a key and it automatically unlocks. As such, you may just have a look during this time and when you then type your password to unlock it you accidentally trigger the "automatic unlock" and type your password in whatever input field is selected. Try as I might, I cannot reproduce this issue. Could you attach a video that depicts the problem occurring? You might need to point your phone at the screen for this. Maybe it is some adjustment by OpenSUSE or so? Don't know whether this is default behavior. I could screencast it, but it is exactly the same behavior as I describe. Just enter your password directly after the screen (automatically) locks. So what exactly cannot you reproduce? Does the "move mouse only seconds after automatic screen lock" not work or what? (In reply to rugk from comment #4) > I could screencast it, but it is exactly the same behavior as I describe. > Just enter your password directly after the screen (automatically) locks. > > So what exactly cannot you reproduce? After the screen locks and I enter my password in the lock screen, it doesn't show up in an open app with a text field. The reason why I requested a screencast is because I cannot reproduce the issue as described, and often a video helps to illustrate exactly how you're triggering it. Moving to screenlocker. Hmm, it's hard to do this screencast and redact it properly etc.
However, may you first be able to answer this question:
> Does the "move mouse only seconds after automatic screen lock" not work[…]?
I assume you're saying you start typing your password whilst you still have the lock screen grace timeout. At which point typing dismisses it and then You can avoid that by setting "Require password after locking" to immediate. Is that what you're referring to? I do want to change the UI whilst we're still in the grace mode so that the textfield isn't visible or maybe even just keep everything black and fade in. I don't think there's any feasible other behavioural change we can make. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! Seems like this is a real issue: if you type your password during the grace period (default 5 seconds), it will be entered into whatever text field was focused, if any. I believe I'm experiencing this on 5.20.x packages in Fedora or something very similar. I'm not sure why but it seems like something has changed in the last couple of weeks. I have had the same password for years for unlocking desktop computers. I've never done this with any messenger, and my usage of messengers hasn't increased. However, in the past couple of weeks, I've leaked my computer's password half a dozen times in various messengers -- sometimes not realizing till someone points it out. It seems like there might be more going on here than just the 5 second grace period. It seems to be related to my monitors turn off from power management (which happens after the screen should've locked from going idle -- 10 minutes until power off, 5 minutes until lock). Perhaps a regression in the 5.20.3,4 -> 5.20.5 cycle? I don't see recent commits that would suggest such a change. I also don't believe I've changed my behavior unlocking my screen though, so this is exceptionally confusing. I'll try to be more aware of what might be causing this, and intentionally try to reproduce it. (In reply to Wyatt Childers from comment #12) > I believe I'm experiencing this on 5.20.x packages in Fedora or something > very similar. I'm not sure why but it seems like something has changed in > the last couple of weeks. > > I have had the same password for years for unlocking desktop computers. I've > never done this with any messenger, and my usage of messengers hasn't > increased. However, in the past couple of weeks, I've leaked my computer's > password half a dozen times in various messengers -- sometimes not realizing > till someone points it out. > > It seems like there might be more going on here than just the 5 second grace > period. It seems to be related to my monitors turn off from power management > (which happens after the screen should've locked from going idle -- 10 > minutes until power off, 5 minutes until lock). > > Perhaps a regression in the 5.20.3,4 -> 5.20.5 cycle? I don't see recent > commits that would suggest such a change. I also don't believe I've changed > my behavior unlocking my screen though, so this is exceptionally confusing. > I'll try to be more aware of what might be causing this, and intentionally > try to reproduce it. After some diagnosis, this is indeed a different issue, see: https://bugs.kde.org/show_bug.cgi?id=433452 What changed is I started using elisa which for some reason suppresses power management like a video player. Cannot reproduce on Wayland with Plasma 5.26. As it has been a while since it was reported, can we please ask you to see if you can reproduce the issue with a recent software version? Like Plasma 5.25, or ideally 5.26? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |