From radon.neon at gmail.com Tue Feb 15 01:18:46 2022 From: radon.neon at gmail.com (Radon Rosborough) Date: Mon, 14 Feb 2022 17:18:46 -0800 Subject: pass ln: for symlinks In-Reply-To: References: Message-ID: Since my last message (quoted below) didn't receive any replies for a few weeks, I'm assuming contributions would not be accepted for the feature I described. But let me know if that's a bad assumption on my part. On Fri, Jan 28, 2022 at 8:56 PM Radon Rosborough wrote: > > Hi friends, > > I've used Pass for several years and I've always wanted a 'pass ln' > command, for creating symlinks within the password store. This is > useful when the same website uses multiple separate domains, which > should be treated interchangeably for the sake of password management. > (Example: stackoverflow.com, stackexchange.com, askubuntu.com, etc.) > > My current workflow is to go into ~/.password-store and create > symlinks manually, e.g. 'ln -s stackoverflow.com > ~/.password-store/askubuntu.com'. Once symlinks are created, they work > exactly as expected for autocompletion, both at the command line and > in all the clients I use, including Browserpass and the Android app. > The only inconvenience is I have to create the symlink and make a > commit manually. > > My proposed new subcommand would go like 'pass ln [--force,-f] > old-path new-path', and it would have just about the same semantics as > 'pass mv' or 'pass cp', except that it would make sure to always > create relative symlinks to avoid accidentally depending on the > location of the user's home directory or anything like that. The > advantage would be correct autocompletion while making the symlink, > and integration with Git like for the other Pass subcommands. > > I see that an idea like (or the same as) this was first brought up in > 2015 and briefly discussed, but never implemented [1], and in 2020 a > patch was submitted but apparently never merged [2]. > > I'd be happy to spend some time seeing this feature through to its > finish, including adding tests and completion scripts if desired. > Would such a contribution be accepted? If so, I'll follow up with a > patch for feedback. > > Best regards, > Radon Rosborough > https://github.com/raxod502 > > P.S. My email configuration filters out mailing lists, so I'd love it if you > could cc me on replies to this thread. > > [1]: https://lists.zx2c4.com/pipermail/password-store/2015-August/001687.html > [2]: https://lists.zx2c4.com/pipermail/password-store/2020-January/003879.html From mail at steefhegeman.com Thu Feb 17 18:41:20 2022 From: mail at steefhegeman.com (Steef Hegeman) Date: Thu, 17 Feb 2022 19:41:20 +0100 Subject: [PATCH] passmenu: more alternatives for dmenu on wayland Message-ID: <20220217184120.47366-1-mail@steefhegeman.com> If dmenu-wl is not available, try to use wofi -d or bemenu instead. --- Hello, There is no standard dmenu alternative for wayland. This makes the script try common* ones. It tries dmenu-wl first for backwards compatibility. * common in the sense that wofi and bemenu are what xdg-desktop-portal-wlr looks for. (I use bemenu myself.) Kind regards, Steef contrib/dmenu/README.md | 9 ++++++--- contrib/dmenu/passmenu | 6 ++++-- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/contrib/dmenu/README.md b/contrib/dmenu/README.md index 8a196cb..1eb8c9d 100644 --- a/contrib/dmenu/README.md +++ b/contrib/dmenu/README.md @@ -4,9 +4,10 @@ clipboard without having to open up a terminal window if you don't already have one open. If `--type` is specified, the password is typed using [xdotool][] instead of copied to the clipboard. -On wayland [dmenu-wl][] is used to replace dmenu and [ydotool][] to replace xdotool. -Note that the latter requires access to the [uinput][] device, so you'll probably -need to add an extra udev rule or similar to give certain non-root users permission. +On wayland [dmenu-wl][] or [wofi][] or [bemenu][] is used to replace dmenu and +[ydotool][] to replace xdotool. Note that the latter requires access to the +[uinput][] device, so you'll probably need to add an extra udev rule or similar +to give certain non-root users permission. # Usage @@ -16,5 +17,7 @@ need to add an extra udev rule or similar to give certain non-root users permiss [xdotool]: http://www.semicomplete.com/projects/xdotool/ [pass]: http://www.zx2c4.com/projects/password-store/ [dmenu-wl]: https://github.com/nyyManni/dmenu-wayland +[wofi]: https://hg.sr.ht/~scoopta/wofi +[bemenu]: https://github.com/Cloudef/bemenu [ydotool]: https://github.com/ReimuNotMoe/ydotool [uinput]: https://www.kernel.org/doc/html/v4.12/input/uinput.html diff --git a/contrib/dmenu/passmenu b/contrib/dmenu/passmenu index 76d92ab..3b0f7a0 100755 --- a/contrib/dmenu/passmenu +++ b/contrib/dmenu/passmenu @@ -9,7 +9,9 @@ if [[ $1 == "--type" ]]; then fi if [[ -n $WAYLAND_DISPLAY ]]; then - dmenu=dmenu-wl + for dmenu in dmenu-wl "wofi -d" bemenu ; do + command -v "${dmenu%% *}" &> /dev/null && break + done xdotool="ydotool type --file -" elif [[ -n $DISPLAY ]]; then dmenu=dmenu @@ -24,7 +26,7 @@ password_files=( "$prefix"/**/*.gpg ) password_files=( "${password_files[@]#"$prefix"/}" ) password_files=( "${password_files[@]%.gpg}" ) -password=$(printf '%s\n' "${password_files[@]}" | "$dmenu" "$@") +password=$(printf '%s\n' "${password_files[@]}" | $dmenu "$@") [[ -n $password ]] || exit -- 2.35.1 From higuita at GMX.net Thu Feb 17 22:40:44 2022 From: higuita at GMX.net (higuita) Date: Thu, 17 Feb 2022 22:40:44 +0000 Subject: pass ln: for symlinks In-Reply-To: References: Message-ID: <20220217224044.541205c6@couracado.motaleite.net> Hi resending, used the wrong email for the list > Since my last message (quoted below) didn't receive any replies for a > few weeks, I'm assuming contributions would not be accepted for the > feature I described. But let me know if that's a bad assumption on my > part. I would love that feature, i too have done that manually a few times and just don't use it more exactly because i have to do it manually ... it feels always that i'm breaking something! Sadly, about the possibility of being merged, only Jason (The Developer!) can give some feedback! I would recommend writing the patch, following the same code style and submit to the list. Jason reports that on new releases he do check for good patches to be merged and a feature like this can be mostly contained, causing little trouble and bloat. Good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946 From git at grubix.eu Fri Feb 18 10:57:55 2022 From: git at grubix.eu (Michael J Gruber) Date: Fri, 18 Feb 2022 11:57:55 +0100 Subject: GPG sub-keys In-Reply-To: fe66f42b-8858-e71e-06ca-d6431c5163fb%40metacode.biz Message-ID: <164518187588.25134.18083543792843453835.git@grubix.eu> Note there is a different though related problem/effect with sub-keys: Adding stronger E and S subkeys is a typical "soft key upgrade path" before one goes the full route of upgrading the primary (C) key and losing all key signatures. As someone mentioned, GnuPG will encrypt to the most recent supported E subkey, which does make sense in the context above, and also in general: if two sides of a channel support various schemes they agree on one and use that (typically the best supported by both ends), not all of them. If you re-init your pass store (say, to replace the e-mail address in .gpg-id by a proper key-id) then pass checks the existing pass store for the need to reencrypt: - pass lists the subkey for all recipients specified in .gpg-id This gives all encryption subkeys, "!" appended makes no difference! - For each stored file, pass lists the subkeys they were encrypted to. For GnuPG users, this will one in the scenario above. - It notices the difference, says "reencrypting to {all the E subkeys}". This was quite a trigger for me - encrypting to the weaker/older E subkey? - Then it reencrypts. For GnuPG users, this means reencrypting to the newest subkey only (possibly needlessly). So, besides doing unnecessary reencryption, pass does not do what it says it does. I know I can expire the older E subkey (and still decrypt), but I'm wondering whether it would make sense for pass to check the actual E subkeys which the local gpg will use, i.e. instead of gpg_keys="$($GPG --list-keys --with-colons "${GPG_RECIPIENTS[@]}" | sed ... use gpg_keys="$(echo test | $GPG -e "${GPG_RECIPIENT_ARGS[@]}" | $GPG -v --decrypt --list-only --keyid-format long | sed ... (leaving out some of the standard options which pass uses). As an intended "side-effect", this would not presume a specific gpg behaviour but rather detect it automatically. Cheers Michael From git at grubix.eu Fri Feb 18 11:27:42 2022 From: git at grubix.eu (Michael J Gruber) Date: Fri, 18 Feb 2022 12:27:42 +0100 Subject: [PATCH] re-init: check for actual encryption keys to use In-Reply-To: <164518187588.25134.18083543792843453835.git@grubix.eu> References: <164518187588.25134.18083543792843453835.git@grubix.eu> Message-ID: <1c464cb119815ef37cf367026ddd42f4c751e43c.1645183367.git.git@grubix.eu> Depending on the gpg implementation, gpg may use all valid encryption subkeys or just the newest/best subkey. This difference becomes relevant when pass checks whether a file in the store needs to be reencrypted after a .gpg-id change, and also when reporting to the user which subkeys it reencrypts to. Make pass check the relevant encryption subkeys which gpg will use by doing a quick test run. This (potentially) reduces the number of required reencryption andd makes sure pass reports the actual subkeys being encrypted to (not more). Signed-off-by: Michael J Gruber --- src/password-store.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/password-store.sh b/src/password-store.sh index 22e818f..60e6e09 100755 --- a/src/password-store.sh +++ b/src/password-store.sh @@ -127,7 +127,7 @@ reencrypt_path() { IFS=";" eval 'GPG_RECIPIENTS+=( $group )' # http://unix.stackexchange.com/a/92190 unset "GPG_RECIPIENTS[$index]" done - gpg_keys="$($GPG $PASSWORD_STORE_GPG_OPTS --list-keys --with-colons "${GPG_RECIPIENTS[@]}" | sed -n 's/^sub:[^idr:]*:[^:]*:[^:]*:\([^:]*\):[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[a-zA-Z]*e[a-zA-Z]*:.*/\1/p' | LC_ALL=C sort -u)" + gpg_keys="$(echo test | $GPG -e "${GPG_RECIPIENT_ARGS[@]}" "${GPG_OPTS[@]}" | LC_ALL=C $GPG $PASSWORD_STORE_GPG_OPTS -v --no-secmem-warning --no-permission-warning --decrypt --list-only --keyid-format long 2>&1 | sed -n 's/^gpg: public key is \([A-F0-9]\+\)$/\1/p' | LC_ALL=C sort -u)" fi current_keys="$(LC_ALL=C $GPG $PASSWORD_STORE_GPG_OPTS -v --no-secmem-warning --no-permission-warning --decrypt --list-only --keyid-format long "$passfile" 2>&1 | sed -nE 's/^gpg: public key is ([A-F0-9]+)$/\1/p' | LC_ALL=C sort -u)" -- 2.35.1.557.gc5783a932c From hey at ahill.io Fri Feb 18 15:19:45 2022 From: hey at ahill.io (Alec Hill) Date: Fri, 18 Feb 2022 10:19:45 -0500 Subject: pass ln: for symlinks In-Reply-To: <20220217224044.541205c6@couracado.motaleite.net> References: <20220217224044.541205c6@couracado.motaleite.net> Message-ID: I'd like to echo that this seems like a very appropriate addition! I'm glad to learn that `pass mv` is a command, as I was recently disgruntled to find I couldn't simply `mv old-password new-password`. `pass ln` feels like a missing feature of that same scope as `pass mv`, just waiting for someone to write a patch. Thanks ~Alec On Thu, Feb 17, 2022 at 5:42 PM higuita wrote: > > Hi > > resending, used the wrong email for the list > > > Since my last message (quoted below) didn't receive any replies for a > > few weeks, I'm assuming contributions would not be accepted for the > > feature I described. But let me know if that's a bad assumption on my > > part. > > I would love that feature, i too have done that manually a few > times and just don't use it more exactly because i have to do it > manually ... it feels always that i'm breaking something! > > Sadly, about the possibility of being merged, only Jason (The > Developer!) can give some feedback! > > I would recommend writing the patch, following the same > code style and submit to the list. Jason reports that on new releases > he do check for good patches to be merged and a feature like this > can be mostly contained, causing little trouble and bloat. > > Good luck > higuita > -- > Naturally the common people don't want war... but after all it is the > leaders of a country who determine the policy, and it is always a > simple matter to drag the people along, whether it is a democracy, or > a fascist dictatorship, or a parliament, or a communist dictatorship. > Voice or no voice, the people can always be brought to the bidding of > the leaders. That is easy. All you have to do is tell them they are > being attacked, and denounce the pacifists for lack of patriotism and > exposing the country to danger. It works the same in every country. > -- Hermann Goering, Nazi and war criminal, 1883-1946 From pashtet04 at gmail.com Fri Feb 18 15:41:11 2022 From: pashtet04 at gmail.com (Pashtet Nolchetyre) Date: Fri, 18 Feb 2022 18:41:11 +0300 Subject: pass ln: for symlinks In-Reply-To: References: Message-ID: <1D3E9FD8-79FC-49DD-80DB-39DADDF948BD@gmail.com> Hey! But you can create symlinks at your fs and get it works Sent from my iPhone > On 18 Feb 2022, at 18:21, Alec Hill wrote: > > ?I'd like to echo that this seems like a very appropriate addition! I'm > glad to learn that `pass mv` is a command, as I was recently > disgruntled to find I couldn't simply `mv old-password new-password`. > `pass ln` feels like a missing feature of that same scope as `pass > mv`, just waiting for someone to write a patch. Thanks ~Alec > > >> On Thu, Feb 17, 2022 at 5:42 PM higuita wrote: >> >> Hi >> >> resending, used the wrong email for the list >> >>> Since my last message (quoted below) didn't receive any replies for a >>> few weeks, I'm assuming contributions would not be accepted for the >>> feature I described. But let me know if that's a bad assumption on my >>> part. >> >> I would love that feature, i too have done that manually a few >> times and just don't use it more exactly because i have to do it >> manually ... it feels always that i'm breaking something! >> >> Sadly, about the possibility of being merged, only Jason (The >> Developer!) can give some feedback! >> >> I would recommend writing the patch, following the same >> code style and submit to the list. Jason reports that on new releases >> he do check for good patches to be merged and a feature like this >> can be mostly contained, causing little trouble and bloat. >> >> Good luck >> higuita >> -- >> Naturally the common people don't want war... but after all it is the >> leaders of a country who determine the policy, and it is always a >> simple matter to drag the people along, whether it is a democracy, or >> a fascist dictatorship, or a parliament, or a communist dictatorship. >> Voice or no voice, the people can always be brought to the bidding of >> the leaders. That is easy. All you have to do is tell them they are >> being attacked, and denounce the pacifists for lack of patriotism and >> exposing the country to danger. It works the same in every country. >> -- Hermann Goering, Nazi and war criminal, 1883-1946 From aclopte at gmail.com Fri Feb 18 17:20:37 2022 From: aclopte at gmail.com (Johannes Altmanninger) Date: Fri, 18 Feb 2022 18:20:37 +0100 Subject: pass ln: for symlinks In-Reply-To: References: Message-ID: <20220218172037.zmgaagjkm4uwny7u@gmail.com> On Mon, Feb 14, 2022 at 05:18:46PM -0800, Radon Rosborough wrote: > Since my last message (quoted below) didn't receive any replies for a > few weeks, I'm assuming contributions would not be accepted for the > feature I described. But let me know if that's a bad assumption on my > part. > > On Fri, Jan 28, 2022 at 8:56 PM Radon Rosborough wrote: > > > > Hi friends, > > > > I've used Pass for several years and I've always wanted a 'pass ln' > > command, for creating symlinks within the password store. This is > > useful when the same website uses multiple separate domains, which > > should be treated interchangeably for the sake of password management. > > (Example: stackoverflow.com, stackexchange.com, askubuntu.com, etc.) > > > > My current workflow is to go into ~/.password-store and create > > symlinks manually, e.g. 'ln -s stackoverflow.com > > ~/.password-store/askubuntu.com'. Once symlinks are created, they work > > exactly as expected for autocompletion, both at the command line and > > in all the clients I use, including Browserpass and the Android app. That makes a ton of sense, I also like this feature. > > The only inconvenience is I have to create the symlink and make a > > commit manually. > > > > My proposed new subcommand would go like 'pass ln [--force,-f] > > old-path new-path', and it would have just about the same semantics as > > 'pass mv' or 'pass cp', except that it would make sure to always > > create relative symlinks to avoid accidentally depending on the > > location of the user's home directory or anything like that. The right, we should probably forbid creation of a symlink that escapes from .password-store > > advantage would be correct autocompletion while making the symlink, > > and integration with Git like for the other Pass subcommands. > > > > I see that an idea like (or the same as) this was first brought up in > > 2015 and briefly discussed, but never implemented [1], and in 2020 a > > patch was submitted but apparently never merged [2]. > > > > I'd be happy to spend some time seeing this feature through to its > > finish, including adding tests and completion scripts if desired. > > Would such a contribution be accepted? If so, I'll follow up with a > > patch for feedback. > > > > Best regards, > > Radon Rosborough > > https://github.com/raxod502 > > > > P.S. My email configuration filters out mailing lists, so I'd love it if you > > could cc me on replies to this thread. > > > > [1]: https://lists.zx2c4.com/pipermail/password-store/2015-August/001687.html > > [2]: https://lists.zx2c4.com/pipermail/password-store/2020-January/003879.html From radon.neon at gmail.com Sat Feb 19 19:48:51 2022 From: radon.neon at gmail.com (Radon Rosborough) Date: Sat, 19 Feb 2022 11:48:51 -0800 Subject: pass ln: for symlinks In-Reply-To: References: Message-ID: > Sadly, about the possibility of being merged, only Jason (The Developer!) can give some feedback! I agree. I'll start work on creating this feature as an extension (pass-ln), unless I receive some confirmation that the contribution would be accepted upstream (which I do think would be a more appropriate place for it). From hugo at heagren.com Mon Feb 21 23:34:11 2022 From: hugo at heagren.com (Hugo Heagren) Date: Mon, 21 Feb 2022 23:34:11 +0000 (UTC) Subject: pass ln: for symlinks In-Reply-To: References: Message-ID: Would just like to add that I would definitely support adding this! I too use the symlinks already and having it formalised would be great. Once its built (and merged if appropriate) I would be happy to extend the emacs package password-store.el to include it. Hugo From pwstore at tetzco.de Sun Feb 27 08:07:46 2022 From: pwstore at tetzco.de (Kai Tetzlaff) Date: Sun, 27 Feb 2022 09:07:46 +0100 Subject: [PATCH] emacs: fix infloop in password-store--run Message-ID: <87y21wg2b1.fsf@tetzco.de> Hello, while using the emacs password-store.el package (latest version from https://git.zx2c4.com/password-store with pass v1.7.4 on Windows/WSL2) I found that certain commands (like password-store--run-generate, password-store--run-remove) cause an infloop in: (defun password-store--run (&rest args) "Run pass with ARGS. Nil arguments are ignored. Returns the output on success, or outputs error message on failure." (let ((output nil) (slept-for 0)) (apply #'password-store--run-1 (lambda (password) (setq output password)) (delq nil args)) (while (not output) (sleep-for .1)) output)) The problem is the `(while (not output) (sleep-for .1))` loop which never receives any output (from the supposedly asynchronous pass process started via `password-store--run-1'). There seems to be a race condition as e.g. stepping through the code in edebug never caused the issue. Also, and this seems really weird, the issue didn't happen when adding passwords to the root directory of the password store (i.e. not in a subdirectory). As mentioned above, I'm running emacs in WSL2 on Windows so this might have an effect on timing. While I'm no expert in emacs process handling, I found code in other packages which solved the 'wait for async process output' problem by using the process object returned from `password-store--run-1' to make sure that process output gets seen/accepted by emacs and check for the termination of the aync process. Applying this to `password-store--run' results in: (let ((output nil) (slept-for 0) (process (apply #'password-store--run-1 (lambda (password) (setq output password)) (delq nil args)))) (accept-process-output process .1 nil t) (while (process-live-p process) (accept-process-output process .1 nil t)) output)) which, at least in my environment, fixes the issue. I've CCed Ian who initially added the async handling in commit 7aa17d0. Maybe he can comment on this? A patch with the change shown above against current master is attached. Best Regards, Kai -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-infloop-in-password-store-run.patch Type: text/x-diff Size: 1817 bytes Desc: not available URL: From pwstore at tetzco.de Sun Feb 27 09:02:47 2022 From: pwstore at tetzco.de (Kai Tetzlaff) Date: Sun, 27 Feb 2022 10:02:47 +0100 Subject: [PATCH] emacs: fix infloop in password-store--run In-Reply-To: <87y21wg2b1.fsf@tetzco.de> (Kai Tetzlaff's message of "Sun, 27 Feb 2022 09:07:46 +0100") References: <87y21wg2b1.fsf@tetzco.de> Message-ID: <87k0dgfzrc.fsf@tetzco.de> Actually, checking the elisp reference manual provided some more insight: If a connection from a process contains buffered data, ?accept-process-output? can return non-?nil? even after the process has exited. Therefore, although the following loop: ;; This loop contains a bug. (while (process-live-p process) (accept-process-output process)) will often read all output from PROCESS, it has a race condition and can miss some output if ?process-live-p? returns ?nil? while the connection still contains data. Better is to write the loop like this: (while (accept-process-output process)) So instead of: > (let ((output nil) > (slept-for 0) > (process (apply #'password-store--run-1 > (lambda (password) > (setq output password)) > (delq nil args)))) > (accept-process-output process .1 nil t) > (while (process-live-p process) > (accept-process-output process .1 nil t)) > output)) it should probably better be: (let ((output nil) (slept-for 0) (process (apply #'password-store--run-1 (lambda (password) (setq output password)) (delq nil args)))) ;; wait for output or process termination (max. wait time: 5s) (while (accept-process-output process 5.0)) output)) I added a timeout which terminates `accept-process-output' after 5s just to make sure that a non-responsive pass process doesn't block emacs. It's debatable if this is needed or even makes any sense. An updated patch is attached. Best Regards, Kai -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-infloop-in-password-store-run.patch Type: text/x-diff Size: 1801 bytes Desc: not available URL: From tino.calancha at gmail.com Mon Feb 28 21:15:52 2022 From: tino.calancha at gmail.com (Tino Calancha) Date: Mon, 28 Feb 2022 22:15:52 +0100 (CET) Subject: [PATCH] emacs: fix infloop in password-store--run In-Reply-To: <87k0dgfzrc.fsf@tetzco.de> References: <87y21wg2b1.fsf@tetzco.de> <87k0dgfzrc.fsf@tetzco.de> Message-ID: <96d8ea36-81b4-9027-ea6b-6cc6765f5356@gmail.com> On Sun, 27 Feb 2022, Kai Tetzlaff wrote: Hi Kai, thank you very much for your report and the patches! > I found that certain commands (like password-store--run-generate, > password-store--run-remove) cause an infloop in: > The problem is the `(while (not output) (sleep-for .1))` loop which > never receives any output (from the supposedly asynchronous pass process > started via `password-store--run-1'). I have no way to test Windows from here. Could you check if you still see the issue with the following patch? --8<-----------------------------cut here---------------start------------->8--- >From 00eaff37e6cff555857cc436967c7449d4269deb Mon Sep 17 00:00:00 2001 From: Tino Calancha Date: Mon, 28 Feb 2022 21:56:23 +0100 Subject: [PATCH] emacs: Check `process-status' in the sentinel --- contrib/emacs/password-store.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/emacs/password-store.el b/contrib/emacs/password-store.el index 61c339e..62239dd 100644 --- a/contrib/emacs/password-store.el +++ b/contrib/emacs/password-store.el @@ -88,9 +88,9 @@ or outputs error message on failure." (setq output (concat output text))) :sentinel (lambda (process state) (cond - ((string= state "finished\n") + ((and (eq (process-status process) 'exit) (zerop (process-exit-status process))) (funcall callback output)) - ((string= state "open\n") (accept-process-output process)) + ((eq (process-status process) 'run) (accept-process-output process)) (t (error (concat "password-store: " state)))))))) (defun password-store--run (&rest args) -- 2.30.2 --8<-----------------------------cut here---------------end--------------->8--- From pwstore at tetzco.de Mon Feb 28 21:52:04 2022 From: pwstore at tetzco.de (Kai Tetzlaff) Date: Mon, 28 Feb 2022 22:52:04 +0100 Subject: [PATCH] emacs: fix infloop in password-store--run In-Reply-To: <96d8ea36-81b4-9027-ea6b-6cc6765f5356@gmail.com> (Tino Calancha's message of "Mon, 28 Feb 2022 22:15:52 +0100 (CET)") References: <87y21wg2b1.fsf@tetzco.de> <87k0dgfzrc.fsf@tetzco.de> <96d8ea36-81b4-9027-ea6b-6cc6765f5356@gmail.com> Message-ID: <87czj6wtff.fsf@tetzco.de> Tino Calancha writes: Hi Tino, > Could you check if you still see the issue with the following patch? no, I didn't. Your patch seems to solve the issue, too. BR, Kai