Add KeepassX support

[dundunn]

KeePassX clears the clipboard after 10s by default, but the clipboard indicator still saves the content.

It would be really nice if the Clipboard Indicator wouldn't save the content at all.

[Tudmotu]

Hi @dunnodun :)
Thanks for reporting this issue. I know of it already, as you can see in #46, but unfortunately I have no clue as to how such a thing can be implemented. In the aforementioned ticket I suggested adding a "safe copy" shortcut (which will be configurable) that will copy the text but remove it after a set period of time. Is this a possible solution for you?

Do you maybe have any other idea?

[dundunn]

Sorry I have little coding experience.
Is it possible for the extension to look into the systems processes? If it's possible than I think it shouldn't be a problem to deactivate saving the content of the clipboard, if a program with the name keepassx2 is running.

[Tudmotu]

Looking through the processes might be an option, but if you are running keepassx in the background at all times, it will make the clipboard manager redundant (since it will not save anything). 😕

[dundunn]

Is it possible for the extension to show a notification or something like this? If so you could notify the user that the private mode is being activated as long as a program like KeePass is running.

Edit:
Ah maybe it's not a good solution, but at least it's a workaround for me. I will try to implement it for me, but since I have that little knowledge it could take some time.

[JPvRiel]

When I tried looking into the Gnome/GTK3 specs / dev info for cliboard features for #46, I couldn't find anything that allows identifying which application pasted the data - so this is a really hard problem. KeePass might be able to delete it because it can read the clipboard and recognise it matches the password, but this poor extension has no clear way of knowing which clipboard items belong to keepass.

At best, maybe there's a way to figure out/observe if an item is deleted from the copy paste buffer and then remove it from history too?

[atmarx]

Dang -- I was going to post a request for keeweb support (or arbitrary application 'ignore' support) but if there's no way to get clipboard metadata... can it check to see what application has focus when the clipboard updates instead (assuming the clipboard is being modified by the focused application) and blacklist certain processes?

[JPvRiel]

keeping track of which window is in focus is about the only nasty workaround - maybe some hit and miss window title/name blacklist matching of sorts would be idea, and browser tabs might make for an extra "interesting" bit of pain.

In the meantime, if you want to keep cleartext passwords from ending up on perminant storage, here's a workarround: #46 (comment)

Also using an encrypted volume or storage medium helps avoid some of the risk.

[JPvRiel]

#78 adds an option so that the on disk cache / regsistry.txt file won't store clipboard content, inlcuding passwords. However, that knowingly breaks clipboard history persistence between gnome-shell sessions (reboot, logoff & login).

Doesn't fix/close this issue. Just a possible mitigation.

[hoshsadiq]

I'm sure this goes without saying but just in case, it would be nice to add support for other password managers too

[guenhter]

Another approach to tackle this issue:
It would be really easy to overcome this issue, if the clipboard indicator would provide shortcuts for "Deactivate clipboard indicator" and "Activate clipboard indicator".

With this two new shortcuts, it is already manually possible to deactivate it, copy the PW and activate the indicator again -> password never added to clipboard indicator, what is good.

But this still is not very convenient. So another feature request on KeePass side must be placed to allow "Pre-Copy-Commands" and "Post-Copy-Commands". So it should then be able to add the Clipboard indicator shortcuts to KeePass and everytime a password is copied, it deactivates the indicator first and activates it again afterwards.

What do you say to this?

[NinjaTurtle007]

Will this be implemented?

[Tudmotu]

Closing this since it's the same as #46.