Ability to exclude a program from the history
ecodz opened this issue · comments
I use KeePassXC as my password manager, but sometimes I need to copy a password out of it. KeePassXC automatically clears the system clipboard after 10 seconds, so the password can't be pasted somewhere by accident. But the password still remains in cliphist's history, which I don't really want. Is there a way to ignore programs like password managers entirely?
how does keepass clear the clipboard? does it just do wl-copy --clear
?
if it does then on master if should work. but only if the last thing in the clipboard is the password
Hello, I have the same problem with password-store.
What password store does it copies last value, then makes sleep and copy back the old value. Obviously it means credentials will stay in the history.
I place below original code from the software for copying (they host code on their own git repo, so you have to git clone). I've tried to modify the code to use wl-copy -c (at the same time using your master's code with a change). It really does not seem to work.
clip() {
if [[ -n $WAYLAND_DISPLAY ]] && command -v wl-copy &> /dev/null; then
local copy_cmd=( wl-copy )
local paste_cmd=( wl-paste -n )
if [[ $X_SELECTION == primary ]]; then
copy_cmd+=( --primary )
paste_cmd+=( --primary )
fi
local display_name="$WAYLAND_DISPLAY"
elif [[ -n $DISPLAY ]] && command -v xclip &> /dev/null; then
local copy_cmd=( xclip -selection "$X_SELECTION" )
local paste_cmd=( xclip -o -selection "$X_SELECTION" )
local display_name="$DISPLAY"
else
die "Error: No X11 or Wayland display and clipper detected"
fi
local sleep_argv0="password store sleep on display $display_name"
# This base64 business is because bash cannot store binary data in a shell
# variable. Specifically, it cannot store nulls nor (non-trivally) store
# trailing new lines.
pkill -f "^$sleep_argv0" 2>/dev/null && sleep 0.5
local before="$("${paste_cmd[@]}" 2>/dev/null | $BASE64)"
echo -n "$1" | "${copy_cmd[@]}" || die "Error: Could not copy data to the clipboard"
(
( exec -a "$sleep_argv0" bash <<<"trap 'kill %1' TERM; sleep '$CLIP_TIME' & wait" )
local now="$("${paste_cmd[@]}" | $BASE64)"
[[ $now != $(echo -n "$1" | $BASE64) ]] && before="$now"
# It might be nice to programatically check to see if klipper exists,
# as well as checking for other common clipboard managers. But for now,
# this works fine -- if qdbus isn't there or if klipper isn't running,
# this essentially becomes a no-op.
#
# Clipboard managers frequently write their history out in plaintext,
# so we axe it here:
qdbus org.kde.klipper /klipper org.kde.klipper.klipper.clearClipboardHistory &>/dev/null
echo "$before" | $BASE64 -d | "${copy_cmd[@]}"
) >/dev/null 2>&1 & disown
echo "Copied $2 to clipboard. Will clear in $CLIP_TIME seconds."
}
I'm not an expert on the subject, but what worries me a bit is the below quote from wl-clipboard doc. Doesn't it mean that secure clipboard state is still not supported by wl-copy? Anyway it also seems to be a quite new feature in wl-clipboard.
However, the currently existing Wayland clipboard protocols don't let wl-clipboard identify the cases where clear and sensitive values should be set, so currently wl-clipboard only ever sets CLIPBOARD_STATE to data or nil.
Hello, sorry to bother you, but I have a hard time making this work. Looking at the code, it should, but maybe I am doing something wrong ?
Here is a small repro without my password manager interfering
$ wl-copy --version
wl-clipboard 2.2.1
$ cliphist version
0.5.0
$ wl-copy "foo"
$ cliphist list
70 foo
$ wl-copy -c
$ cliphist list
70 foo
According to release notes, this feature is in the 5.0.0
, but cliphist
still list the last entry after explicitly clearing the clipboard with wl-copy -c
Using cliphist
from nixpkgs unstable installed through home manager, if that can help
ah, it seems wl-clipboard does not support CLIPBOARD_STATE=clear yet. from the man page:
Any client programs implementing the CLIPBOARD_STATE protocol are encouraged to implement proper support for all the values listed above, as well as to fall back to some sensible behavior if CLIPBOARD_STATE is unset or set to some unrecognized value (this is to leave the design space open for future extensions). However, the currently existing Wayland clipboard protocols don't let wl-clipboard identify the cases where clear and sensitive values should be set, so currently wl-clipboard only ever sets CLIPBOARD_STATE to data or nil.
can be verified if you do, in one terminal
$ wl-paste --watch sh -c "env | grep CLIPBOARD_STATE"
and another
$ wl-copy -c
when the clear is issued the other prints CLIPBOARD_STATE=nil
so i think we need to wait until the wayland protocols are developed further