[pass] Concurrency issue with --clip

Michael Ren micron33 at gmail.com
Mon Mar 10 21:53:36 CET 2014

On 03/10/2014 06:28 AM, Stephen Blott wrote:
> Yes, I thought of raising a similar issue recently:
> 1. pass show -c password1
> 2. Fiddle for 40 seconds getting to the right web page
> 3. Doh!, I'm about to run out of time, so:
>    pass show -c password1 (again)
> 4. After another 5 seconds (40 + 5) the clipboard reverts to its
> original contents.
> This whole clipping/clearing business could use some more thought.  It
> probably needs to store some state in a file somewhere: the last
> non-password clipboard text, the process identifiers of outstanding
> clipboard-reset processes, ...
> However, perhaps you'll all come down on me like a tone of bricks, but:
>    - would it really be that bad just to leave the password in the
> clipboard?
> As soon as the password hits the clipping *at all* it's visible to all
> other X applications.
> Steve

There are a few contrived social engineering scenarios where clearing
the password after 45 seconds would help, but the main reason I could
see the 45-second feature being useful is to prevent you from
accidentally re-entering the password on the screen later.

Say you're editing a Google Doc and copy your Google password to the
clipboard. A couple minutes later, you need to copy a URL to the doc,
but you forget to control-c it, and when you control-v in the doc you
paste your password. Now all the collaborators can see it, and it may
even be archived in the revision history b/c of auto-save.

This sort of thing isn't going to happen every day, but it's still nice
to have the peace of mind of pasting without worrying about that. Having
a password in the clipboard indefinitely is, well... indefinite.

It doesn't really matter what's in the clipboard as long as it's not any
password, which is why I'm currently just clearing the clipboard after
"sleep 45". Pass already does this for Klipper's clipboard.

Also, if we were to fix --clip (not the proposed --Clip), one way to do
it without tracking state would be through the judicious use of pkill,
esp. w/ -x, to kill previous pass processes. One could filter out
long-running pass instances (e.g. "pass edit ...") by filtering for "-c"
in the full command line (pkill's -f flag).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20140310/f8e29891/attachment.asc>

More information about the Password-Store mailing list