While on lockscreen, pressing ctrl-v or clicking mid mouse button will copy selected text (if any) from clipboard. Then, it can be showed by pressing the "show" button. This is a privacy issue (i guess) as an extraneous person can access user clipboard (even if only most recent item).
What Plasma version is this? The clipboard should be cleared if you lock the screen [1] and [2]. [1] https://cgit.kde.org/kscreenlocker.git/commit/?id=cae1e82fc94f23f735ae3c189030505a95810cb5 [2] https://cgit.kde.org/kscreenlocker.git/commit/?id=b69465e5b115717f4dbe7fb1d0a496926816a690
Sorry, forgot that! $ pacman -Q kscreenlocker kscreenlocker 5.11.4-1 I'm on X11.
It might be that Arch reverted the changes. IIRC some distros reverted them.
I can't see any reverting patch here: https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/kscreenlocker. The only patch i see is https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kscreenlocker&id=3cde934f21af20462b85db6e36cc6a718b3c188f.
This is still reproducible with kscreenlocker 5.13.4-1 on Arch Linux. As you can see, there are no patches applied here: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kscreenlocker&id=46441a992c346e1f1aea0ae32fde56c518f96396 Behavior on other systems: gnome-screensaver 3.6.1-8ubuntu3 (Ubuntu 18.04): clears clipboard Windows 10: disables copy/paste in lock screen. Clipboard is not cleared.
Could it be that you have Klipper configured to prevent empty clipboard?
I can confirm that the "prevent empty clipboard" option causes the described behavior
(In reply to Martin Flöser from comment #6) > Could it be that you have Klipper configured to prevent empty clipboard? Confirmed. If the option is disabled, then the clipboard is indeed cleared. However, there is still a (small) integrity issue, anyone can modify the clipboard contents while the screen is locked.
I'm changing the state of the bug. What we have here is correct and expected behavior. If one configures to prevent empty clipboard exactly that is provided. We cannot disable the clipboard for lock screen on X11 - in Wayland this is implemented. So overall a worksforme.
While it might be technically completely logical given the current implementation, I would argue that this is still not the expected/intended behavior. I would never have thought that this Klipper setting actually has this behavior. Expected behavior: Clipboard should be disabled on lockscreen (ctrl-x, ctrl-c, ctrl-v, middle-mouse click should not change the input field nor the clipboard contents of the session). (Related: Undo/Redo should probably also be disabled, bug 387418.) Do you have some references to source code/documentation/concepts on why for example Klipper has this influence? Would it be feasible the modify the lockscreen to implement the above expected behavior? (If you think it is reasonable and doable, I might give it a try.)
No it's not feasible or doable on X11, sorry. What we want is to disable the clipboard, but such functionality does not exist. On Wayland we do have the required control and don't pass clipboard to the lock screen. But on X11 we just don't have the control and hack around. We clear the clipboard and Klipper restores it. We don't know that Klipper restored it and Klipper cannot know that it was the lock screen.
(In reply to Martin Flöser from comment #11) > No it's not feasible or doable on X11, sorry. What we want is to disable the > clipboard, but such functionality does not exist. If clearing it does not work, what about putting in a dummy value? There are a few text fields (at least the username and password), even if it is not possible at the X11 level, isn't it possible to set an event filter and filter keyboard/pointer events? > We don't know that Klipper restored it and Klipper > cannot know that it was the lock screen. So I guess I'll have to look into Klipper and the kscreenlocker source code. However, currently this bug is marked as resolved which is not appropriate I think. Are you open to patches to address it?
(In reply to Peter Wu from comment #12) > (In reply to Martin Flöser from comment #11) > > No it's not feasible or doable on X11, sorry. What we want is to disable the > > clipboard, but such functionality does not exist. > > If clearing it does not work, what about putting in a dummy value? > > There are a few text fields (at least the username and password), even if it > is not possible at the X11 level, isn't it possible to set an event filter > and filter keyboard/pointer events? No > > > We don't know that Klipper restored it and Klipper > > cannot know that it was the lock screen. > > So I guess I'll have to look into Klipper and the kscreenlocker source code. > However, currently this bug is marked as resolved which is not appropriate I > think. Are you open to patches to address it? No, I'm not open to any patches. This issue is fixed on Wayland and we have a feature freeze on X11.
This is a problem. That is not blocked for fixes. We can probably do something at a theme level. Worst case I will ship my patch removing the reveal password button.
Git commit 1638db3fefcae76f27f889b3709521b608aa67ad by David Edmundson. Committed on 20/08/2018 at 12:49. Pushed by davidedmundson into branch 'Plasma/5.12'. Prevent paste in screen locker Summary: KScreenlocker tries to clear the clipboard on load. However, klipper also (by default) automatically keeps the last relevant item in the clipboard. Whilst both parts independently work correctly, Plasma as a whole does not. This became a problem when we added the reveal password button as it is a data leak. Instead of clearing the clipboard this patch replaces it with a real entry, but with a dummy mime value that is of no value to anyone, especially a textfield. Test Plan: Reproduced issue Made this patch Tried pasting in session Nothing happned Logged in Could paste Reviewers: #plasma, mart Reviewed By: mart Subscribers: mart, graesslin, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D14924 M +15 -2 greeter/greeterapp.cpp https://commits.kde.org/kscreenlocker/1638db3fefcae76f27f889b3709521b608aa67ad
Thanks David. Wouldn't this patch result in dummy entries in the Klipper history? If so, would it be possible to prevent this from happening (can Klipper detect the entry/exit of lockscreen?)
>Wouldn't this patch result in dummy entries in the Klipper history? No. Klipper only stores text mimetypes by default, optionally including images.