Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Add support for x-kde-passwordManagerHint mimetype #11

Open
bugzy opened this issue Apr 26, 2022 · 6 comments
Open

[Feature Request] Add support for x-kde-passwordManagerHint mimetype #11

bugzy opened this issue Apr 26, 2022 · 6 comments

Comments

@bugzy
Copy link

bugzy commented Apr 26, 2022

KDE's clipboard manager has a persistent history feature, but allows for the possibility of adding an item to the clipboard so that it can be immediately pasted, but it doesn't get added to the history at all. To do this, the x-kde-passwordManagerHint mimetype needs to be added to the list of mimetypes for the paste data. This would be a nice thing to do here, so that when you copy a password to paste it into a text field that was not able to be automatically populated, there is no risk of a password being leaked into the user's plaintext history.
See https://phabricator.kde.org/D12539 for more information.

Quoted from: ttyridal/masterpassword-firefox#85 (comment)
I am not sure that setting this hint is available through Dbus but it is probably worthwhile following up on this. I know that Plasma Pass uses the feature; see commit but that is not written Python and neither does it use the Dbus API. Once I inquire a little more about this, I can update this issue.

@naglfar
Copy link
Owner

naglfar commented Apr 28, 2022

As far as I've seen there is no method in the dbus interface to access this function, so this would probably need an extra binary to handle this.

@bugzy
Copy link
Author

bugzy commented May 2, 2022

Been digging in the klipper code to see if exposing this setting to DBUS is doable without much knowledge ;) This seems to be the relevant section of the code:
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/klipper/klipper.cpp#L277
Currently the setClipboardContents takes only one variable. it should be able to take 2, one for the string and one for the metadata. Moreover the function should be expanded to include the metadata setting.

@bugzy
Copy link
Author

bugzy commented May 2, 2022

I am looking to see if I can propose this adjustment to the klipper maintainer once I find out who that is.

@bugzy
Copy link
Author

bugzy commented Jun 29, 2022

@naglfar I found an alternative to this mimetype support. It turns out that there is a krunner SecretService plugin from a year ago that was written to work with keepassxc:

The author wrote the plugin in python and has an implementation for clearing klipper. If this can be integrated here, the only thing left to implement would be the delay before clearing the keyboard. I suppose it can be made a configurable value in the config file.

@naglfar
Copy link
Owner

naglfar commented Jun 29, 2022

The original intent of this issue was to keep the copied password out of the klipper history, was it not? I'm pretty sure the linked project does not achieve this, it just clears the clipboard after a few seconds, keeping the entry in history either way.
There is a function to completely clear all of klippers history but that seems overkill and unnecessarily inconvenient.
I can (and will) add the automatic clearing of the clipboard and add the delay as a config value, it's just not a feature I ever cared much for myself since I don't think it adds much in terms of security.

@bugzy
Copy link
Author

bugzy commented Jun 30, 2022

There is a function to completely clear all of klippers history but that seems overkill and unnecessarily inconvenient.
I can (and will) add the automatic clearing of the clipboard and add the delay as a config value, it's just not a feature I ever cared much for myself since I don't think it adds much in terms of security.

If the proposal in #11 (comment) does not keep it out of the history then it may not be worth your time to implement as you have suggested. I agree that clearing the entire klipper history would be overkill and would be considered a bug. I can keep looking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants