[pass] Concurrency issue with --clip

[Michael Ren]

On 03/10/2014 04:53 PM, Michael Ren wrote:
> 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).
> 
> Michael
> 
Please excuse the bottom-posting b/c I believe Steve wanted to post this
to the mailing list but ended up sending only to me.

-------------- 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/14a667f9/attachment-0001.asc>