From sacredirritant at gmail.com  Wed May  8 19:07:16 2024
From: sacredirritant at gmail.com (sacredirritant)
Date: Wed,  8 May 2024 14:07:16 -0500
Subject: [PATCH] emacs: Don't require a matching password in
 password-store-edit
Message-ID: <20240508190750.3326-1-sacredirritant@gmail.com>

This aligns password-store-edit with pass edit.
---
 contrib/emacs/CHANGELOG.md      | 4 ++++
 contrib/emacs/password-store.el | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/contrib/emacs/CHANGELOG.md b/contrib/emacs/CHANGELOG.md
index e15414f..4fc7e0f 100644
--- a/contrib/emacs/CHANGELOG.md
+++ b/contrib/emacs/CHANGELOG.md
@@ -1,3 +1,7 @@
+# 2.3.3
+
+* (bugfix) Don't require a matching password in password-store-edit.
+
 # 2.3.2
 
 * (bugfix) Ensure the system clipboard is cleared after
diff --git a/contrib/emacs/password-store.el b/contrib/emacs/password-store.el
index c7cc991..759f170 100644
--- a/contrib/emacs/password-store.el
+++ b/contrib/emacs/password-store.el
@@ -4,7 +4,7 @@
 
 ;; Author: Svend Sorensen <svend at svends.net>
 ;; Maintainer: Tino Calancha <tino.calancha at gmail.com>
-;; Version: 2.3.2
+;; Version: 2.3.3
 ;; URL: https://www.passwordstore.org/
 ;; Package-Requires: ((emacs "26.1") (with-editor "2.5.11"))
 ;; SPDX-License-Identifier: GPL-3.0-or-later
@@ -236,7 +236,7 @@ ENTRY is the name of a password-store entry."
 ;;;###autoload
 (defun password-store-edit (entry)
   "Edit password for ENTRY."
-  (interactive (list (password-store--completing-read t)))
+  (interactive (list (password-store--completing-read)))
   (password-store--run-edit entry))
 
 ;;;###autoload
-- 
2.42.0


From raffeck at cs.fau.de  Wed May 15 13:34:25 2024
From: raffeck at cs.fau.de (Phillip Raffeck)
Date: Wed, 15 May 2024 15:34:25 +0200
Subject: [PATCH] Die on GPG reencryption error
Message-ID: <ba1480af192c82d7a79a9602fb5040f4183f6d18.1715779499.git.raffeck@cs.fau.de>

If reencryption of the password store fails, pass nonetheless creates a
commit for reencryption and exits with status code 0. This path
introduces error handling to fail on reencryption errors.
---
 src/password-store.sh | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/password-store.sh b/src/password-store.sh
index 22e818f..5c82785 100755
--- a/src/password-store.sh
+++ b/src/password-store.sh
@@ -110,6 +110,7 @@ set_gpg_recipients() {
 reencrypt_path() {
 	local prev_gpg_recipients="" gpg_keys="" current_keys="" index passfile
 	local groups="$($GPG $PASSWORD_STORE_GPG_OPTS --list-config --with-colons | grep "^cfg:group:.*")"
+	local err=0
 	while read -r -d "" passfile; do
 		[[ -L $passfile ]] && continue
 		local passfile_dir="${passfile%/*}"
@@ -133,11 +134,14 @@ reencrypt_path() {
 
 		if [[ $gpg_keys != "$current_keys" ]]; then
 			echo "$passfile_display: reencrypting to ${gpg_keys//$'\n'/ }"
-			$GPG -d "${GPG_OPTS[@]}" "$passfile" | $GPG -e "${GPG_RECIPIENT_ARGS[@]}" -o "$passfile_temp" "${GPG_OPTS[@]}" &&
-			mv "$passfile_temp" "$passfile" || rm -f "$passfile_temp"
+			$GPG -d "${GPG_OPTS[@]}" "$passfile" | $GPG -e "${GPG_RECIPIENT_ARGS[@]}" -o "$passfile_temp" "${GPG_OPTS[@]}"
+			gpgerr=$?
+			[[ $gpgerr -eq 0 ]] && mv "$passfile_temp" "$passfile" || rm -f "$passfile_temp"
+			err=$(($err+$gpgerr))
 		fi
 		prev_gpg_recipients="${GPG_RECIPIENTS[*]}"
 	done < <(find "$1" -path '*/.git' -prune -o -path '*/.extensions' -prune -o -iname '*.gpg' -print0)
+	return $err
 }
 check_sneaky_paths() {
 	local path
@@ -361,7 +365,7 @@ cmd_init() {
 		fi
 	fi
 
-	reencrypt_path "$PREFIX/$id_path"
+	reencrypt_path "$PREFIX/$id_path" || die "Could not reencrypt password store"
 	git_add_file "$PREFIX/$id_path" "Reencrypt password store using new GPG id ${id_print%, }${id_path:+ ($id_path)}."
 }
 
-- 
2.45.0

From password-store at city17.xyz  Sat May 25 19:44:41 2024
From: password-store at city17.xyz (jman)
Date: Sat, 25 May 2024 21:44:41 +0200
Subject: [PATCH] Extend --clip/--qrcode to support copying/displaying
 non-password fields
In-Reply-To: <D0SK3838IX4V.3BQLZ3J51RUT4@gmail.com> (Dan Crawford's message of
 "Wed, 24 Apr 2024 21:15:03 +0300")
References: <D0SK3838IX4V.3BQLZ3J51RUT4@gmail.com>
Message-ID: <8734q54qxi.fsf@city17.xyz>

"Dan Crawford" <dnlcrwfrd at gmail.com> writes: 
 
> This patch extends --clip (and incidentally, --qrcode) to support either copying arbitrary lines 
> (with the existing syntax), or copying the value of some field. Given the above passfile, 
> --clip="field1" or -c"field1" will add `key1` to the clipboard.

Hi and thanks for this patch, I can finally remove the workaround I use to programmatically get 
other fields (.. | head -n).

I have probably a corner case where this patch fails:

supersecretpass
login: mechanik
url: https://www.ecommerce.com

`pass <item> --clip=url` copies only "https:" and not the full URL. 

Second question: do you mind reformatting your patch with `git format-patch` so I can cleanly apply 
it to my passwordstore.sh and keep credits intact? 

Thanks!

From dnlcrwfrd at gmail.com  Mon May 27 10:37:23 2024
From: dnlcrwfrd at gmail.com (Dan Crawford)
Date: Mon, 27 May 2024 13:37:23 +0300
Subject: [PATCH] Extend --clip/--qrcode to support copying/displaying
 non-password fields
In-Reply-To: <8734q54qxi.fsf@city17.xyz>
References: <D0SK3838IX4V.3BQLZ3J51RUT4@gmail.com> <8734q54qxi.fsf@city17.xyz>
Message-ID: <D1KD0S3ORVB6.BBNX5QQON8C2@gmail.com>

Good catch! Luckily it's easy to fix that edge case.

I attach a git-formatted patch including this fix.
Please let me know if there are any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Extend-clip-qrcode-to-support-copying-displaying-nonpassword-fields.patch
Type: text/x-patch
Size: 2428 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20240527/cb926b9f/attachment.bin>

From password-store at city17.xyz  Mon May 27 12:49:51 2024
From: password-store at city17.xyz (jman)
Date: Mon, 27 May 2024 14:49:51 +0200
Subject: [PATCH] Extend --clip/--qrcode to support copying/displaying
 non-password fields
In-Reply-To: <D1KD0S3ORVB6.BBNX5QQON8C2@gmail.com> (Dan Crawford's message of
 "Mon, 27 May 2024 13:37:23 +0300")
References: <D0SK3838IX4V.3BQLZ3J51RUT4@gmail.com> <8734q54qxi.fsf@city17.xyz>
 <D1KD0S3ORVB6.BBNX5QQON8C2@gmail.com>
Message-ID: <87bk4r1ksw.fsf@city17.xyz>

"Dan Crawford" <dnlcrwfrd at gmail.com> writes: 
 
> Good catch! Luckily it's easy to fix that edge case. 
> 
> I attach a git-formatted patch including this fix.  Please let me know if there are any issues. 

thanks!

The copied text contains a leading space (f.e. " text") but I can
live with that :)

From dnlcrwfrd at gmail.com  Mon May 27 13:06:56 2024
From: dnlcrwfrd at gmail.com (Dan Crawford)
Date: Mon, 27 May 2024 16:06:56 +0300
Subject: [PATCH] Extend --clip/--qrcode to support copying/displaying
 non-password fields
In-Reply-To: <87bk4r1ksw.fsf@city17.xyz>
References: <D0SK3838IX4V.3BQLZ3J51RUT4@gmail.com>
 <8734q54qxi.fsf@city17.xyz> <D1KD0S3ORVB6.BBNX5QQON8C2@gmail.com>
 <87bk4r1ksw.fsf@city17.xyz>
Message-ID: <D1KG7AFL73AM.29643CEDUG24F@gmail.com>

Really? For me there is no leading space (GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu))
If there is a space that could actually be quite annoying --- in the
previous version of this patch I had a trim() function to remove such
spaces. I can add that function back to ensure there are no issues.

From org_password_store at xrad.org  Wed May 29 11:02:44 2024
From: org_password_store at xrad.org (Conrad Hughes)
Date: Wed, 29 May 2024 12:02:44 +0100
Subject: Symlinks, again
Message-ID: <E1sCH4v-002ERW-05@rin>

I can see that over the years many requests and contributions for better
symbolic link handling seem to have been made, but symlinks are still a
source of breakage today (v1.7.4 on Debian).  Based on a cursory read,
past contributions (e.g. February/March 2022) have tried to fix more
than just the below bug, but as far as I can see have never been
acknowledged, let alone accepted.  Was the reasoning ever explained
off-list?

Personally I'd be happy to just add symlinks to the git repo manually,
but I'm still regularly stymied by pass then failing to edit them
correctly.  The basic bug here is exemplified by (for example):

  1. Add a symlink so b points to a:

     cd ~/.password-store
     ln -s a.gpg b.gpg
     git add b.gpg
     git commit -a -m 'Symlink.'

  2. Edit it via the symlink:

     pass edit b

  3. Pass won't have realised that b was a symlink, and the git repo
     will now have a.gpg modified and uncommitted:

     pass git status

Conrad

From richard at freakingpenguin.com  Thu May 30 16:12:40 2024
From: richard at freakingpenguin.com (Richard Sent)
Date: Thu, 30 May 2024 12:12:40 -0400
Subject: Resolve .gpg-id files must end in a newline to be recognized
Message-ID: <875xuv9t3b.fsf@freakingpenguin.com>

Hi all,

To create subdirectories in .password-store that are encrypted
using a different gpg key, the user needs to create a .gpg-id file in
that subdirectory. What isn't obvious however is that that .gpg-id file
needs to end in a newline, not just the keyid. If the user fails to do
that, they will be shown a warning like this:

--8<---------------cut here---------------start------------->8---
~/rsent/rsent/machines $ pass generate LAN/restic
You did not specify a user ID. (you may use "-r")

Current recipients:

Enter the user ID.  End with an empty line: 
gpg: signal Interrupt caught ... exiting
interrupt
--8<---------------cut here---------------end--------------->8---

At this point the user may choose to enter the UID manually. However,
there's no indication that this problem is caused by missing a newline
in .gpg-id. ("End with an empty line" is gpg referring to ending
interactive uid input)

I think password-store should either:

1. Handle .gpg-id files where the last entry does not end in a newline
2. Display an explicit error if it fails to read the recipient from a
.gpg-id file, or at least if the file does not end in a newline.

Pass version: 1.7.4

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

From grimm at puzzle.ch  Fri May 31 07:57:28 2024
From: grimm at puzzle.ch (Lukas Grimm)
Date: Fri, 31 May 2024 09:57:28 +0200
Subject: [PATCH] Fix zsh completion for multiple repositories
Message-ID: <91fdb82c-a352-43fa-b278-5658c3eece1c@puzzle.ch>

Hi all,

is there a Reason this patch wasn't implemented? The current 
zsh-completion won't work with multiple Passwordstore Repositories as 
soon as you use a command, this patch would fix this behavior.

Thanks

-- 
Lukas Grimm
Lead System Engineer

Puzzle ITC GmbH
www.puzzle.ch

Telefon +41 31 370 22 00