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

Jason A. Donenfeld Jason at zx2c4.com
Sat Mar 22 04:55:05 CET 2014

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

>    - 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:

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

More information about the Password-Store mailing list