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

[Jason A. Donenfeld]

On Fri, Mar 21, 2014 at 10:45 AM, Stephen Blott <smblott at gmail.com> wrote:
>
> The issues are described below.  However, fundamentally, the problem is
> that password-store is doing concurrent programming without any concurrency
> control.  Which doesn't work.
>

The current solution, which uses signals, which is in fact a concurrency
primitive.


>
>
>    - https://github.com/smblott-github/password-store/compare/locking


In the future, would you mind using git-send-email? I could then reply
inline about code issues.


>
>
>
> 1. With two concurrent background processes, the second restores the
> first's password, leaving a password in the clipboard.
>
> 2. With two concurrent background processes, the clipboard is restored by
> the first before the 45 seconds of the second have elapsed.
>
>
The current solution using that "kill" line solves these two issues in
basically 3 lines:
http://git.zx2c4.com/password-store/commit/?id=2c9c36e3ca8eab1a3f9056d18619f80cedf3781d

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20140321/30779eef/attachment-0001.html>