Closed ohnonot closed 5 years ago
I have the same query. I use KeePass2, and would like to exclude everything coming from a window containing "KeePass" in the application bar title. Any way to achieve this in Clipit?
please see this forum post. that seems to be the state of things :-(
Indeed, the strings that are to be inserted into clipit's history are checked against the regular expressions in the list, and if they match any of the regexes, they are ignored by clipit. This was mainly thought for ignoring specific strings (for example URLs, matching http://) not that much for passwords. I didn't check if it is possible to ignore strings that come from a specific app, so I'm not really sure if that's possible at all, but if anyone has a patch/pull request for that, I'd be happy to accept it.
Someone found a solution for that?
A work around might be to ask the window manager for the xproperties of the window that is currently focused and check that against some regex.
Can somebody please edit the issue title to correctly reflect the fact that the exclusion does not fully work as intended -- i.e. it's buggy. In particular, the least I'd recommend urgently fixing is the explanatory text in the Preferences > Exclude as it's rather misleading. The text clearly states that the feature is intended for password exclusion, but one can't seriously suggest that users should enter a list of all their plain text passwords that will than be saved plain text in ClipIt's setting just to avoid having plain text passwords saved in the history.
Secondly @johntyree's solution sounds reasonable, is there a bounty page or something where important featured can be advertised?
I'll have a look at this when I get the chance. Maybe I can implement @johntyree's idea as well.
pszi1ard:
The text clearly states that the feature is intended for password exclusion, but one can't seriously suggest that users should enter a list of all their plain text passwords that will than be saved plain text in ClipIt's setting just to avoid having plain text passwords saved in the history.
this is not entirely correct. in my version of clipit it says: "Regex list of items that should not be inserted into the history" afaik the feature works, but i'm not very good with regular expressions so i haven't fully tested it.
for example, i think it would be possible to formulate a regular expression that would exclude all passwords that are exactly nn characters long, so in that case the passwords themselves wouldn't show up anywhere. but imo that's a fragile workaround at best; i think 99% of users would like to exclude passwords based on the originating application.
how would you like me to edit the title? i will try something else...
afaik the feature works, but i'm not very good with regular expressions so i haven't fully tested it.
"Regex list list of items" is hardly clear; what exactly are items and what is a "regex list" of these? Frankly, it has never crossed my mind that one would ever consider writing a regex to match passwords simply because it's silly to do so -- you'll either end up with a way too broadly matching regex or leaking part of one's passwords in an effort to try to not have them leak through the history. Consequently, it's sensible to assume that the help text is just a confusing mess many of us programmers tend write when we're finally almost done and it's just that pesky text that separates us from the git push followed by patting ourselves on the back.
for example, i think it would be possible to formulate a regular expression that would exclude all passwords that are exactly nn characters long,
You mean one that matches any string of N characters. Does not make sense:
So what about pre/post fixing all passwords with some short string, that is highly unlikely to appear in normal texts one usually works with? Do you guys see this as viable workaround until window title based exclusion is implemented? For example use this exclusion regex
^pw9.*
to exclude all clipboard contents, that start with strings pw9
I'm experimenting with this and it seems to work so far. Also I think it is secure, even if the prefix is leaked to attacker, who would try brute forcing your password. So they know first few characters, they still have to guess the rest, which is totally independent on the prefix. And most hashes used for auth purposes these days should be very difficult to crack, even if attacker knows part of the cleartext AFAIK.
Any thoughts on this?
So what about pre/post fixing all passwords with some short string,
I personally would not change all my passwords just to work around the limitations of clipit and I'm not sure anyone would.
Regex exclusion, as others have pointed out, is not suitable for password exclusion. It's a fine feature on its own for other purposes, but not identifying passwords. Credit card numbers, sure. SSN, sure. Passwords, obviously not.
There needs to be some signal that either prevents clipit from storing the next clip, or makes it easy to wipe the previous clip. Ideally it's the former and it happens automatically. The only solution I can think of for that is using xproperties. Maybe others have other ideas. A distant second is having a hotkey to disable clipit from saving the next clip. Users can invoke that when they know they are going to be copying a password. An even more distant third is providing a way to wipe the previous copy.
All three can be useful, but I think the order is as I've listed them.
Thanks for comments!
I personally would not change all my passwords just to work around the limitations of clipit and I'm not sure anyone would.
Periodical change of all passwords is good opportunity for that. Maybe not everyone has such habit. This would be good opportunity to develop it.
Regex exclusion, as others have pointed out, is not suitable for password exclusion.
My idea is different and wasn't covered by previous discussion. Adding short prefix to all passwords still seems viable approach to me even with the setup cost of revisiting all accounts I maintain. The other available option, switching to offline mode whenever I handle passwords, is not very convenient for me. But YMMV.
Ok, the answer to implementing this is XGetSelectionOwner(), check out pull request below.
Sadly this does not work reliably. I still get passwords from Keepass in Clipit. I haven't figured out yet when this happens and when it doesn't.
what version of keepass do you have? are you on X.org or Wayland? is ClipIt providing any info on console?
On Wed, May 22, 2019 at 10:24 PM Michael notifications@github.com wrote:
Sadly this does not work reliably. I still get passwords from Keepass in Clipit. I haven't figured out yet when this happens and when it doesn't.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CristianHenzel/ClipIt/issues/48?email_source=notifications&email_token=ALGZSKB24K2RL4QXSZV5IWTPWWTXZA5CNFSM4CAW2G32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWAHILA#issuecomment-494957612, or mute the thread https://github.com/notifications/unsubscribe-auth/ALGZSKEF4SYWM4O5GNJ7O2DPWWTXZANCNFSM4CAW2G3Q .
Keepass 2.41 X.Org 1.19.2 Kernel: 4.19.0-1-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0 Desktop: Xfce 4.12.3 Distro: MX-18.2_x64 Continuum March 14 2018 base: Debian GNU/Linux 9 (stretch)
When entering clipit
into console I get this message:
(clipit:5481): Gdk-CRITICAL **: 21:21:43.736: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed
I still couldn't find out when this bug happens and when it doesn't. But it seems that there is always a --
as part of the history when it does. Maybe it has to do with Keepass' automatic clearing of the clipboard?
so what are your exact clipit settings?
On Thu, May 23, 2019 at 9:48 PM Michael notifications@github.com wrote:
Keepass 2.41 X.Org 1.19.2 Kernel: 4.19.0-1-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0 Desktop: Xfce 4.12.3 Distro: MX-18.2_x64 Continuum March 14 2018 base: Debian GNU/Linux 9 (stretch)
When entering clipit into console I get this message: (clipit:5481): Gdk-CRITICAL **: 21:21:43.736: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed
I still couldn't find out when this bug happens and when it doesn't. But it seems that there is always a -- as part of the history when it does. Maybe it has to do with Keepass' automatic clearing of the clipboard?
[image: image] https://user-images.githubusercontent.com/30999326/58281856-760a3600-7da4-11e9-89d4-a9d1d6a8fb2b.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CristianHenzel/ClipIt/issues/48?email_source=notifications&email_token=ALGZSKG23WCQVXLAJSNHUQTPW3YKLA5CNFSM4CAW2G32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWDJR3Q#issuecomment-495360238, or mute the thread https://github.com/notifications/unsubscribe-auth/ALGZSKHEPMFNV7VQMYJH3N3PW3YKLANCNFSM4CAW2G3Q .
There is no apparent issue with the settings. Please drop a line, if you find, how to reproduce the problem.
On Mon, Jun 3, 2019 at 9:30 PM Michael notifications@github.com wrote:
[image: grafik] https://user-images.githubusercontent.com/30999326/58828736-66ada700-8646-11e9-9a42-fbec91e5adbe.png [image: grafik] https://user-images.githubusercontent.com/30999326/58828792-847b0c00-8646-11e9-926a-531da2ebab6f.png [image: grafik] https://user-images.githubusercontent.com/30999326/58828810-9197fb00-8646-11e9-96f7-65632789f3f4.png [image: grafik] https://user-images.githubusercontent.com/30999326/58828835-a07ead80-8646-11e9-9eb7-ba416b062f5a.png [image: grafik] https://user-images.githubusercontent.com/30999326/58828857-ab394280-8646-11e9-83db-0c8cb2699e9e.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CristianHenzel/ClipIt/issues/48?email_source=notifications&email_token=ALGZSKCJIQV47ISSPOFH4FTPYVWMJA5CNFSM4CAW2G32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW2OHEI#issuecomment-498394001, or mute the thread https://github.com/notifications/unsubscribe-auth/ALGZSKGHRYWF5LWTUER4LJTPYVWMJANCNFSM4CAW2G3Q .
This issue is actually solved by a clear-clipboard API that KeepassXC is using. Parcellite doesn't support it: https://github.com/rickyrockrat/parcellite/issues/86 Does ClipIt support this?
Oh look, I opened that issue years ago!
And no,it doesn't.
Keepassxc has improved so much in the last 7 years that there is no situation where I'd have to copy a password to the clipboard at all. If I still do, I can always delete it from clipit's history manually.
If you constantly run into this issue, you need to change your keepassxc usage habits.
This is an endless discussion - a clipboard manager saves clipboard entries to a history. Arguably that's already a security risk in itself, and it'snot its job to doanything about it. Arguably! But I'm not going to. If you disagree, create a pull request that implements the desired feature.
Yes, generally I agree with you, but beside the usual usage with KeepassXC there are still a lot of situations where I need to copy a password via clipboard, and KeepassXC therefore has the feature to delete it from clipboard managers after a timeout.
I'm not sure if you're confusing the clipboard itself with the clipboard manager (which is basically just a saved history of the former).
Do you know of any clipboard manager that implements the feature you mentioned?
Please read on https://github.com/keepassxreboot/keepassxc/issues/9842 It should be a free desktop.org standard and other clipboard managers have implemented that. However I'm no expert and I'm still looking around for a clipboard manager fulfilling my needs.
I cannot find documentation anywhere? It says "Regex list of items that should not be inserted". it does work when i insert the actual password as regex, but i find that nonsensical. so, would the passwords to be excluded have to contain a string that would make them recognizable? or can the feature be used to e.g. tell clipit "do not remember anything copied from keepassx"?