SUMMARY Clipboard Manager, when using Bitwarden to copy passwords and other sensitive fields that are flagged as such, gets stuck into Clipboard Manager history immediately upon copy. This bug was filed against KDE Connect previously as well, and I've confirmed, when disabling the "Sync passwords" option in KDE Connect that this data is not synced, therefore confirming that the data being copied has the appropriate information to define it being sensitive, yet it's being retained in Clipboard Manager history, in plain text. STEPS TO REPRODUCE 1. Install/Open/Use Bitwarden, and copy a password using the copy button on a password. 2. Click on Clipboard Manager tray icon, see password in the clear in history. OBSERVED RESULT Password and sensitive data is retained in Clipboard Manager history in plain. EXPECTED RESULT Clipboard Manager does not retain this sensitive information openly and visible. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 ADDITIONAL INFORMATION This was previously discussed about KDE Connect here: https://discuss.kde.org/t/copy-sensitive-info-without-saving-it-to-clipboard-history/10555/3
Can verify this behavior on git-master In the Bitwarden GUI, used the Copy button to copy a password Looked at the clipboard history, saw the password
> when disabling the "Sync passwords" option in KDE Connect This only works if KDE Connect and Clipper are able to know that the copied text is a password. And that gets done in the sending app, when it marks the copied data as a password by sending along the `x-kde-passwordManagerHint` MIME hint along with the copied text. Evidently BitWarden doesn't do this. See https://invent.kde.org/utilities/kwalletmanager/-/merge_requests/46 for an example of how this was implemented for KWallet a few months ago. So I'd recommend bringing this up with the BitWarden folks.
Why would this work with KDE Connect, with the option to sync passwords is turned off, and it doesn't sync passwords, but with it turned on (the default), it does sync it? This suggests to me that it is indeed setting the hint, at least at some level. Cause it's clearly seen when you adjust KDE Connect settings off and back on again.
Apparently also Pano, on GNOME, as an extension, seems to be able to work with this as well.. So this is very well KDE specific...
An alternative for the time being would be fairly simple, too, if there was a reasonable option for that. To be able to omit specifically named windows in focus so that app's clipboard contents optionally don't get sent to the Clipboard Manager history, since in Wayland, Clipboard manager seems to be a required core part of Plasma. *SOMETHING* needs to happen and not just ignoring the whole problem. :/
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4932
My mistake, sorry! Bad assumption.
Turns out to be a bug (or expected behavior) in GTK. Gdk.ContentProvider doesn't like mimetypes without a slash.
Git commit 8dea08961a02f0b36c5a7fa7e75b8eecfdf338bc by Fushan Wen. Committed on 21/11/2024 at 07:54. Pushed by fusionfuture into branch 'master'. appiumtests: test clip with secret hint should not be saved in history When a mimedata has "x-kde-passwordManagerHint" set to "secret", the clip should not be saved to history. M +1 -1 appiumtests/applets/CMakeLists.txt M +13 -1 appiumtests/applets/clipboardtest.py A +46 -0 appiumtests/applets/clipboardtest/copysecret.py https://invent.kde.org/plasma/plasma-workspace/-/commit/8dea08961a02f0b36c5a7fa7e75b8eecfdf338bc
(In reply to Fushan Wen from comment #8) > Turns out to be a bug (or expected behavior) in GTK. Gdk.ContentProvider > doesn't like mimetypes without a slash. Did that change recently?
And does this "upstream fix" really fix the real issue? If the issue is that the mime-type used for this doesn't work without slashes, that alone is a huge bug because there's literally no mime-type that doesn't have a <maintype>/<subtype>. Secondly, and maybe this could/should be in another ticket, but another approach to helping solve some of this issue, and this is what Pano in part does, and since Clipboard Manager has the ability, to check what window is active, and be able to filter retaining history results on specific applications, if they're the active focused window. In Wayland this can't simply be done by just anything, but where Clipboard Manager is running, I'm at least betting on the possibility that *it* can identify what's active when it's determining a new entry hits the clipboard, yes?
(In reply to Eric Renfro from comment #11) > And does this "upstream fix" really fix the real issue? If the issue is that > the mime-type used for this doesn't work without slashes, that alone is a > huge bug because there's literally no mime-type that doesn't have a > <maintype>/<subtype>. The clipboard itself supports mime types without slashes, but GTK filters them out. Actually they are only represented as string keys in the clipboard and a key can be any string. > > Secondly, and maybe this could/should be in another ticket, but another > approach to helping solve some of this issue, and this is what Pano in part > does, and since Clipboard Manager has the ability, to check what window is > active, and be able to filter retaining history results on specific > applications, if they're the active focused window. In Wayland this can't > simply be done by just anything, but where Clipboard Manager is running, I'm > at least betting on the possibility that *it* can identify what's active > when it's determining a new entry hits the clipboard, yes? It should be possible on both platforms. To implement that a window filter is needed.
> The clipboard itself supports mime types without slashes, but GTK filters them out. Actually they are only represented as string keys in the clipboard and a key can be any string. Even still. A properly defined mime-type does in fact have a maintype/subtype structure, always has. It seems unusual to have one without a subtype instead of something like text/x-kde-passwordManagerHint versus text/plain for example. > It should be possible on both platforms. To implement that a window filter is needed. On this, though.. Considering this ticket keeps getting closed, what's the next steps to try to actually genuinely resolve the overall problem here? Cause, password managers exist, they contain sensitive information, Clipboard Manager has access to see what window is in focus at the very least...