[pass] Clip/restore concurrency issues (fix?)

[Stephen Blott]

On Fri, Mar 21, 2014 at 09:55:05PM -0600, Jason A. Donenfeld wrote:
>Anyway -- can you raise any technical arguments as to why the flock
>solution is better? I agree that my "sleep 0.1" is technically racy
>(though this could be fixed by inotify watching on /proc/$ppid and
>checking the monotonic start time bla bla), but in practice it seems to
>be pretty perfect.
---end quoted text---

Technical arguments?  There are race conditions.

On Fri, Mar 21, 2014 at 09:55:05PM -0600, Jason A. Donenfeld wrote:
>Your solution is quite hefty and writes passwords unencrypted to disk (!).
>An improvement to this would be to use tmpfs, as we do for `pass edit`.
>Also, you'll probably want to use $DISPLAY as part of the write/read lock
>file names, since a user might be using the same store with multiple X
>servers at once.
---end quoted text---

I've reworked it such that only the clipboard contents are written to 
files.

Here's an example where using the DISPLAY variable in file names would be 
incorrect.  Two parallel ssh sessions from the same X server/client to the 
same host, both with X forwarding.  They have different values for 
$DISPLAY, but are actually sharing the same clipboard.

And here's an example where using the DISPLAY variable in file names would 
be correct.  Two parallel ssh sessions from *different* X servers/clients 
but to the same host.  They are not sharing the same clipboard.

For me, at least, the former is common.  The latter isn't.

On Fri, Mar 21, 2014 at 09:55:05PM -0600, Jason A. Donenfeld wrote:
>In the future, would you mind using git-send-email? I could then reply
>inline about code issues.
---end quoted text---

I'll try.

I have a new version which incorporates a number of the ideas people have 
posted, and avoids putting passwords into the files system at all.  And -- 
I think -- there are no race conditions.

I'll post that separately.

Steve

(Now, off to see if I can figure out how git-send-email works...)