On Fri, Mar 21, 2014 at 10:45 AM, Stephen Blott <[email protected]> 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.
_______________________________________________ Password-Store mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/password-store
