From tom at sanctum.geek.nz  Wed May 21 02:43:06 2025
From: tom at sanctum.geek.nz (Tom Ryder)
Date: Wed, 21 May 2025 14:43:06 +1200
Subject: Editor backup files
In-Reply-To: <E1trFnS-000F5m-0K@rin>
References: <E1trFnS-000F5m-0K@rin>
Message-ID: <aC09unEVxuuLsfDv@shaka>

On Sun, Mar 09, 2025 at 12:30:47PM +0000, Conrad Hughes wrote:
>One way around this is to configure the editor not to create backups 
>when editing in /dev/shm.  Have people taken any other approaches?

There's a plugin in v1.7.4 for this called `redact_pass.vim`: 
<https://git.zx2c4.com/password-store/tree/contrib/vim?h=1.7.4>

-- 
Tom Ryder <https://sanctum.geek.nz/>
Maybe we can bring back the light.

From mail at rkta.de  Wed May 21 04:36:59 2025
From: mail at rkta.de (Rene Kita)
Date: Wed, 21 May 2025 06:36:59 +0200
Subject: Editor backup files
In-Reply-To: <E1trFnS-000F5m-0K@rin>
References: <E1trFnS-000F5m-0K@rin>
Message-ID: <20250521043659.GI2272@t480.rkta.de>

On Sun, Mar 09, 2025 at 12:30:47PM +0000, Conrad Hughes wrote:
> My editor (vim) creates backup files automatically, which in the case of
> 'pass edit' is something of a security leak ? it'll fill your editor
> backup dir with files like
> 
>   %dev%shm%pass.xyzxyzxyzxyzx%xyzxyz-passentry.txt~
> 
> One way around this is to configure the editor not to create backups
> when editing in /dev/shm.  Have people taken any other approaches?
> 
> Conrad

My vim is configured to place the backup file next to the original.
After closing vim the whole directory in /dev/shm is gone.

From craig at theagricolas.org  Wed May 21 18:14:21 2025
From: craig at theagricolas.org (Craig B Agricola)
Date: Wed, 21 May 2025 14:14:21 -0400
Subject: Editor backup files
In-Reply-To: <E1trFnS-000F5m-0K@rin>
References: <E1trFnS-000F5m-0K@rin>
Message-ID: <20250521181421.GI22048@theagricolas.org>

I use redact_pass.vim, which is in the git repository (at
contrib/vim/redact_pass.vim).  It handles disabling the swap files when using
pass, and gives you a handy message that you can check for to be sure that it
has done so.  It disables writing to the viminfo, as well, so if you delete
something, the deleted text doesn't get written to a register that then gets
written to your viminfo file.  I suspect it's better than rolling your own
solution, because it's had multiple eyes over it.

 -Craig

On Sun, Mar 09, 2025 at 12:30:47PM +0000, Conrad Hughes wrote:
> My editor (vim) creates backup files automatically, which in the case of
> 'pass edit' is something of a security leak ??? it'll fill your editor
> backup dir with files like
> 
>   %dev%shm%pass.xyzxyzxyzxyzx%xyzxyz-passentry.txt~
> 
> One way around this is to configure the editor not to create backups
> when editing in /dev/shm.  Have people taken any other approaches?
> 
> Conrad

From igor at c4llv07e.xyz  Wed May 21 18:54:52 2025
From: igor at c4llv07e.xyz (c4llv07e)
Date: Wed, 21 May 2025 21:54:52 +0300
Subject: New project fork?
Message-ID: <8qmpdcar.fsf@c4llv07e.xyz>

I've noticed that there's no activity in the main repository for a long
time already. Does anyone have an alternative git repo with new commits
from this mailing list?


From mail at maxkapral.com  Thu May 22 01:21:25 2025
From: mail at maxkapral.com (Maxwell Kapral)
Date: Wed, 21 May 2025 18:21:25 -0700 (PDT)
Subject: New project fork?
In-Reply-To: <8qmpdcar.fsf@c4llv07e.xyz>
References: <8qmpdcar.fsf@c4llv07e.xyz>
Message-ID: <e8ae6fac-8b4c-40dd-a341-952a64e9b802@maxkapral.com>

+1

May 21, 2025 11:57:39 c4llv07e <igor at c4llv07e.xyz>:

> I've noticed that there's no activity in the main repository for a long
> time already. Does anyone have an alternative git repo with new commits
> from this mailing list?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20250521/9326b9cf/attachment.sig>

From gcoakes at solidoak.dev  Thu May 22 04:07:48 2025
From: gcoakes at solidoak.dev (Gregory Oakes)
Date: Wed, 21 May 2025 23:07:48 -0500
Subject: New project fork?
In-Reply-To: <e8ae6fac-8b4c-40dd-a341-952a64e9b802@maxkapral.com>
References: <8qmpdcar.fsf@c4llv07e.xyz>
 <e8ae6fac-8b4c-40dd-a341-952a64e9b802@maxkapral.com>
Message-ID: <870d7237-168e-4657-bc21-44c83752ca5f@solidoak.dev>

What new feature development or bug fixes are you looking for 
specifically in this fork? I ask for two reasons:

1. I, as a user, generally consider password-store to be feature 
complete without need for major feature development. I am happy with the 
current implementation and do not wish for it to change. New features 
would mean new complexity which must be maintained/validated and which 
may introduce instability/insecurity.

2. Social pressure like this is exactly how the XZ supply chain attack 
started. That included multiple users piling onto an already 
over-stressed maintainer to influence them to believe that someone else 
should maintain the project. password-store which naturally handles 
sensitive data seems like a ripe target to me.

If there really is no maintenance happening for security issues or 
similar, I don't want to dissuade. I have admittedly not closely 
followed or ever engaged with this mailing list before.

Please just keep this useful tool continuing to be useful and trustworthy.

From ngraves at ngraves.fr  Thu May 22 04:52:36 2025
From: ngraves at ngraves.fr (Nicolas Graves)
Date: Thu, 22 May 2025 06:52:36 +0200
Subject: New project fork?
References: <87plg1dztu.fsf@ngraves.fr>
Message-ID: <87msb5dz6z.fsf@ngraves.fr>


-------------------- Start of forwarded message --------------------
From: Nicolas Graves <ngraves at ngraves.fr>
To: Gregory Oakes <gcoakes at solidoak.dev>
Subject: Re: New project fork?
Date: Thu, 22 May 2025 06:38:53 +0200

On 2025-05-21 23:07, Gregory Oakes wrote:

> What new feature development or bug fixes are you looking for 
> specifically in this fork? I ask for two reasons:

On my side, I'm unable to receive an answer for a more general API so
that a few option changes are enough to support age/rage instead of
gnupg as an encryption backend, at least on the emacs side.

Despite multiple pings and a pledge to do it myself if maintainers agree
on the project, I'm simply stuck between either an incomplete patching
of pass or a whole copy/duplicated effort with the passage.el package
(which is not a satisfying solution either).

I don't think it's too niche as a requirement.  IMHO, you can't claim to
a standard without providing an extensible library or API, and IMHO pass
currently doesn't do that well.

> 1. I, as a user, generally consider password-store to be feature 
> complete without need for major feature development. I am happy with the 
> current implementation and do not wish for it to change. New features 
> would mean new complexity which must be maintained/validated and which 
> may introduce instability/insecurity.

Indeed, I think it's the case for most users.  Maybe doing a wishlist to
clarify what feature a fork might benefit from is a necessity before
forking.  It might also clarify what features are priorities, and which
ones are not.

I might also add some things like embark/transient interoperability in
Emacs, but I haven't tried it so I don't really know how well it's
already integrated in modern emacs APIs.

> 2. Social pressure like this is exactly how the XZ supply chain attack 
> started. That included multiple users piling onto an already 
> over-stressed maintainer to influence them to believe that someone else 
> should maintain the project. password-store which naturally handles 
> sensitive data seems like a ripe target to me.

TY for reminding that.

> If there really is no maintenance happening for security issues or 
> similar, I don't want to dissuade. I have admittedly not closely 
> followed or ever engaged with this mailing list before.
>
> Please just keep this useful tool continuing to be useful and trustworthy.

-- 
Best regards,
Nicolas Graves
-------------------- End of forwarded message --------------------

-- 
Best regards,
Nicolas Graves

From igor at c4llv07e.xyz  Thu May 22 05:28:00 2025
From: igor at c4llv07e.xyz (c4llv07e)
Date: Thu, 22 May 2025 05:28:00 +0000
Subject: New project fork?
In-Reply-To: <870d7237-168e-4657-bc21-44c83752ca5f@solidoak.dev>
References: <8qmpdcar.fsf@c4llv07e.xyz>
 <e8ae6fac-8b4c-40dd-a341-952a64e9b802@maxkapral.com>
 <870d7237-168e-4657-bc21-44c83752ca5f@solidoak.dev>
Message-ID: <54d257f1-792b-4827-b297-d1d90fc8aea1@c4llv07e.xyz>

> 1. I, as a user, generally consider password-store to be feature
> complete without need for major feature development. I am happy with the
> current implementation and do not wish for it to change. New features
> would mean new complexity which must be maintained/validated and which
> may introduce instability/insecurity.

There's some bugs and some problems with current implementation, fixing
which wouldn't increase complexity. There's some problems with man page
that were fixed in patch from Dec 2024; bash completion is bugged and
doesn't work with pass-otp. This is two bugs was issued here in less
than a year (which is a lot for a dead mailing list). Pass is very good
software, but as any other software, it is not without bugs.

Still, as a user, I would like to see some improvements in current
version, because right now it only works with X11, not on Wayland
(xdotool doesn't work in non-X11 apps). It was also fixed by my patches
long time ago and by some patches from jimum3bxg6c4 at gmail.com. It
isn't in upstream yet.

I understand concern about complexity, but it shouldn't break existing
workflows and should only add small features.

> 2. Social pressure like this is exactly how the XZ supply chain attack
> started. That included multiple users piling onto an already over-
> stressed maintainer to influence them to believe that someone else
> should maintain the project. password-store which naturally handles
> sensitive data seems like a ripe target to me.

This is a really good concern. Maybe since it's a simple Bash script, it
will be easier to check for backdoors inside.

But yes, it is very possible, I can't argue against it.

> If there really is no maintenance happening for security issues or
> similar, I don't want to dissuade. I have admittedly not closely
> followed or ever engaged with this mailing list before.

The only thing I can think of is that pass is built on X-keylogger
protocol, where any app can already read your passwords, so there are no
security vulnerabilities that aren't there by design. /joke

From trice at posteo.net  Thu May 22 05:42:41 2025
From: trice at posteo.net (Tim Rice)
Date: Thu, 22 May 2025 05:42:41 +0000
Subject: New project fork?
In-Reply-To: <870d7237-168e-4657-bc21-44c83752ca5f@solidoak.dev>
References: <8qmpdcar.fsf@c4llv07e.xyz>
 <e8ae6fac-8b4c-40dd-a341-952a64e9b802@maxkapral.com>
 <870d7237-168e-4657-bc21-44c83752ca5f@solidoak.dev>
Message-ID: <aC65UUqDFFhAy0Cz@sleipnir.acausal.realm>

OP isn't the only one wondering this, and this isn't the first time it's been mentioned that the project seems to be unmaintained. The last commit to the Git repo was nearly two years ago.

I haven't agitated about it because I haven't minded too much just rolling patches in my local copy.

For what it's worth, these are commits which I run in my personal fork:

```
$ git log --cherry 1.7.4...personal/1.7.4
bd0b28e (2023-11-20) pass (HEAD -> personal/1.7.4, origin/personal/1.7.4) Move gpg-ids to body of commit message to keep header short
1b0a367 (2023-11-06) pass delete: Allow specifying multiple paths to remove
6fcdbe6 (2023-11-06) pass edit: Add option --force/-f to allow recrypting one file
2f8dc91 (2023-10-13) pass Update manpage to match primary-selection patches
a400d31 (2023-10-12) pass generate: Add option --primary/-p to use primary selection
df51bce (2023-09-28) pass show: Add option --primary/-p to use primary selection
```

If the maintainer (Jason?) says they are still alive and still interested in the project, that would be a good start to reassuring those of us who have some concerns about the current status of the project, i.e. that it seems to be pretty much dead.


>What new feature development or bug fixes are you looking for
>specifically in this fork? I ask for two reasons:

I like the look of these, or at least wonder why they haven't been reviewed one way or the other for possible inclusion:

https://lists.zx2c4.com/pipermail/password-store/2024-June/004860.html
https://lists.zx2c4.com/pipermail/password-store/2024-September/004869.html
https://lists.zx2c4.com/pipermail/password-store/2024-June/004859.html
https://lists.zx2c4.com/pipermail/password-store/2024-May/004847.html
https://lists.zx2c4.com/pipermail/password-store/2024-May/004852.html
https://lists.zx2c4.com/pipermail/password-store/2024-January/004807.html
https://lists.zx2c4.com/pipermail/password-store/2023-October/004780.html
https://lists.zx2c4.com/pipermail/password-store/2023-September/004770.html
https://lists.zx2c4.com/pipermail/password-store/2023-March/004745.html
https://lists.zx2c4.com/pipermail/password-store/2023-February/004732.html
https://lists.zx2c4.com/pipermail/password-store/2023-January/004703.html
https://lists.zx2c4.com/pipermail/password-store/2022-August/004639.html

When a project is in a healthy state, someone with authority to merge patches or implement fixes would give an answer: yes we'll merge, no we won't do that because foo, or please change x, y and z because bar and baz.


>1. I, as a user, generally consider password-store to be feature
>complete without need for major feature development. I am happy with the
>current implementation and do not wish for it to change. New features
>would mean new complexity which must be maintained/validated and which
>may introduce instability/insecurity.

This looks like FUD. A project doesn't need rapid implementation of dodgy new features to still be healthy, quite the opposite. What it does need is a maintainer who cares enough to review patches and reply to bug reports.

If you're happy with version 1.7.4, no one is coming to your house to force you to change. Or if a better maintained fork exists, no one is going to force you to switch to it.

You are perfectly free to use unmaintained software forever, and when there is a security bug that doesn't get fixed I guess that's something you'll just have to decide for yourself how to prepare for.


>2. Social pressure like this is exactly how the XZ supply chain attack
>started. That included multiple users piling onto an already
>over-stressed maintainer to influence them to believe that someone else
>should maintain the project. password-store which naturally handles
>sensitive data seems like a ripe target to me.

It's *not* exactly the same. That's not a fair comparison at all. Jason has not been active here for years, despite a wide variety of people actively participating in the mailing list and asking for updates on their patches and bug reports without any response.

Projects change hands or get forked all the time as the original maintainers lose the ability to commit to a project for whatever reason.

I myself adopted a project, GNU Datamash, because the previous maintainer fell off the radar for a while.

Go check the Datamash archives yourself before you accuse me of being some xz style agent. You'll see a history of questioning what happened to the previous maintainer, followed by me adopting the project, followed by years of me being involved in discussing about patches, features and bug reports.

Make sure to report me to the GNU project if you suspect I'm a secret agent who is corrupting Datamash after I volunteered to make sure it doesn't die.


>If there really is no maintenance happening for security issues or
>similar, I don't want to dissuade. I have admittedly not closely
>followed or ever engaged with this mailing list before.

Well, the archives exist, so maybe you should check first and come to an opinion later. When was the last time Jason replied, and how much do you really want to stand in the way of people who just want software to get a bit of TLC every now and then?


>Please just keep this useful tool continuing to be useful and trustworthy.

You seem to be worried about one sensational case which isn't the norm in free software. All the OP was asking was whether a better-maintained fork exists.

No one is forcing you to move to a fork if it does exist. No one is trying to pressure the current maintainer, if he's even still here, to merge dodgy patches. Myself, and I guess OP, would just prefer to know we are using software that gets a bit of TLC.

There is a difference between software that is feature complete and software that is dead.

~ Tim


On Wed, May 21, 2025 at 11:07:48PM -0500, Gregory Oakes wrote:
>What new feature development or bug fixes are you looking for
>specifically in this fork? I ask for two reasons:
>
>1. I, as a user, generally consider password-store to be feature
>complete without need for major feature development. I am happy with the
>current implementation and do not wish for it to change. New features
>would mean new complexity which must be maintained/validated and which
>may introduce instability/insecurity.
>
>2. Social pressure like this is exactly how the XZ supply chain attack
>started. That included multiple users piling onto an already
>over-stressed maintainer to influence them to believe that someone else
>should maintain the project. password-store which naturally handles
>sensitive data seems like a ripe target to me.
>
>If there really is no maintenance happening for security issues or
>similar, I don't want to dissuade. I have admittedly not closely
>followed or ever engaged with this mailing list before.
>
>Please just keep this useful tool continuing to be useful and trustworthy.

From Jason at zx2c4.com  Thu May 22 06:14:58 2025
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 22 May 2025 08:14:58 +0200
Subject: New project fork?
In-Reply-To: <aC65UUqDFFhAy0Cz@sleipnir.acausal.realm>
References: <8qmpdcar.fsf@c4llv07e.xyz>
 <e8ae6fac-8b4c-40dd-a341-952a64e9b802@maxkapral.com>
 <870d7237-168e-4657-bc21-44c83752ca5f@solidoak.dev>
 <aC65UUqDFFhAy0Cz@sleipnir.acausal.realm>
Message-ID: <CAHmME9r5H=jMP3YiqsmEgSB111ziKWck8Xma_eA6YfYbqtsFMA@mail.gmail.com>

On Thu, May 22, 2025 at 7:44?AM Tim Rice <trice at posteo.net> wrote:
> If the maintainer (Jason?) says they are still alive and still interested in the project, that would be a good start to reassuring those of us who have some concerns about the current status of the project, i.e. that it seems to be pretty much dead.

Still alive. Still interested. Not dead.

From trice at posteo.net  Thu May 22 06:27:43 2025
From: trice at posteo.net (Tim Rice)
Date: Thu, 22 May 2025 06:27:43 +0000
Subject: New project fork?
In-Reply-To: <CAHmME9r5H=jMP3YiqsmEgSB111ziKWck8Xma_eA6YfYbqtsFMA@mail.gmail.com>
References: <8qmpdcar.fsf@c4llv07e.xyz>
 <e8ae6fac-8b4c-40dd-a341-952a64e9b802@maxkapral.com>
 <870d7237-168e-4657-bc21-44c83752ca5f@solidoak.dev>
 <aC65UUqDFFhAy0Cz@sleipnir.acausal.realm>
 <CAHmME9r5H=jMP3YiqsmEgSB111ziKWck8Xma_eA6YfYbqtsFMA@mail.gmail.com>
Message-ID: <aC7D31L99qa-gnwy@sleipnir.acausal.realm>

>Still alive. Still interested. Not dead.

Haha, nice, and thanks for replying :)

~ Tim

From password-store at dirkmb.de  Thu May 22 08:29:31 2025
From: password-store at dirkmb.de (Dirk Braunschweiger)
Date: Thu, 22 May 2025 10:29:31 +0200
Subject: xclip -loops for pass
In-Reply-To: <e5ilfl3nz7lckfcgnxijwxmuics3yffxhigms2mznzi63hkd7l@uogpgqadkg5c>
References: <e5ilfl3nz7lckfcgnxijwxmuics3yffxhigms2mznzi63hkd7l@uogpgqadkg5c>
Message-ID: <aC7gazozcAye-Jrg@dirkmb-t14>

Hey Martin,

this feature really sounds great. I did not know about the -loops
parameter. For pasting the pastword it would be a good solution.

Concerning the username feature: I would really like this! Currently I
have some local changes for using the second clipboard to store the
username. But beeing able to post the username once and afterwards the
password once sounds like a better solution.

Best regards,
Dirk

On Wed, Apr 23, 2025 at 07:21:54PM +0200, martin f. krafft wrote:
> Folks,
>
> I just had a bit of fun with `pass`, and one of the things I did was try to
> come up with a wrapper that would put the username on the clipboard until it
> was pasted, and then the password, until it was pasted. I used `xclip -loops
> 1` for that.
>
> And this made me realise: `pass` uses `xclip` internally, right? Why the 45
> second wait and overwrite? `xclip -loops 1` makes the password available
> once exactly, and after a paste, the clipboard is empty.
>
> What's more: wouldn't this be cool functionality? `pass both
> example.org/uid` and I get the username for one paste, and then the password
> for one paste?
>
> Looking forward to your thoughts?
>
> Best,
>
> --
> martin krafft | https://matrix.to/#/#madduck:madduck.net
>
> weapon, n.:
>  an index of the lack of development of a culture.
> {: .blockquote }
>
> spamtraps: madduck.bogus at madduck.net
> {: .hidden }
>

From igor at c4llv07e.xyz  Thu May 22 12:16:00 2025
From: igor at c4llv07e.xyz (c4llv07e)
Date: Thu, 22 May 2025 12:16:00 +0000
Subject: [PATCH] Die on GPG reencryption error
In-Reply-To: <ba1480af192c82d7a79a9602fb5040f4183f6d18.1715779499.git.raffeck@cs.fau.de>
References: <ba1480af192c82d7a79a9602fb5040f4183f6d18.1715779499.git.raffeck@cs.fau.de>
Message-ID: <75a7ef11-7459-4347-877b-23fa22cb8e4d@c4llv07e.xyz>

Can't it just be done by `set -e` at the beginning of the function and
`set +e` at the end? It will fix this problem, I think.

From ikwyl6 at protonmail.com  Thu May 22 21:23:42 2025
From: ikwyl6 at protonmail.com (ikwyl6)
Date: Thu, 22 May 2025 21:23:42 +0000
Subject: New project fork?
In-Reply-To: <aC7D31L99qa-gnwy@sleipnir.acausal.realm>
References: <8qmpdcar.fsf@c4llv07e.xyz>
 <e8ae6fac-8b4c-40dd-a341-952a64e9b802@maxkapral.com>
 <870d7237-168e-4657-bc21-44c83752ca5f@solidoak.dev>
 <aC65UUqDFFhAy0Cz@sleipnir.acausal.realm>
 <CAHmME9r5H=jMP3YiqsmEgSB111ziKWck8Xma_eA6YfYbqtsFMA@mail.gmail.com>
 <aC7D31L99qa-gnwy@sleipnir.acausal.realm>
Message-ID: <Qv1ynK_BkeZChd3LEDEXmz3NfL8jclek9QDoi3zIZfS3e4AHTON4pKj9AJTU9Y8_vzjF-ckm57KHpkwGVXd0F5Z7cjhamVhRTfL_pc_pIwU=@protonmail.com>

Would it be just as easy for someone to start a 'password-store patches' repo on github and then it's done..? Sync the code with zx2c4.. The PR's can be listed and you can pick and choose which ones you want to use.. then they are atleast listed there that someone can search and find (instead of combing through mailing list).. If author doesn't want to host patches/PR/changes then this can be done.. I would assume this would be the easiest thing in this situation..




On Thursday, 22 May 2025 at 03:31, Tim Rice <trice at posteo.net> wrote:

> 
> 
> >Still alive. Still interested. Not dead.
> 
> 
> Haha, nice, and thanks for replying :)
> 
> ~ Tim

From quoiceehoh-20180826 at yxejamir.net  Fri May 23 13:53:54 2025
From: quoiceehoh-20180826 at yxejamir.net (Amir Yalon)
Date: Fri, 23 May 2025 16:53:54 +0300
Subject: Editor backup files
In-Reply-To: <E1trFnS-000F5m-0K@rin>
References: <E1trFnS-000F5m-0K@rin>
Message-ID: <532705a2-392e-4fee-8980-ab0a5944a40a@app.fastmail.com>

There is a Vim/Neovim plugin in contrib that is worth being aware of:

https://git.zx2c4.com/password-store/tree/contrib/vim/redact_pass.vim

This plugin switches off not only the 'backup' option, but also 'viminfo', 'swapfile', 'undofile' and others; see its accompanying txt file. It is also available in Debian and derivatives as vim-redact-pass.

Cheers,
Amir

On Sun, 9 Mar 2025, at 14:30, Conrad Hughes wrote:
> My editor (vim) creates backup files automatically, which in the case of
> 'pass edit' is something of a security leak ? it'll fill your editor
> backup dir with files like
>
>   %dev%shm%pass.xyzxyzxyzxyzx%xyzxyz-passentry.txt~
>
> One way around this is to configure the editor not to create backups
> when editing in /dev/shm.  Have people taken any other approaches?
>
> Conrad

From org_password_store at xrad.org  Fri May 30 11:49:06 2025
From: org_password_store at xrad.org (Conrad Hughes)
Date: Fri, 30 May 2025 12:49:06 +0100
Subject: Editor backup files
In-Reply-To: <532705a2-392e-4fee-8980-ab0a5944a40a@app.fastmail.com>
References: <E1trFnS-000F5m-0K@rin>
 <532705a2-392e-4fee-8980-ab0a5944a40a@app.fastmail.com>
Message-ID: <E1uKyDR-0005A7-0N@rin>

I'm a little confused that a message sent in early March only seemed to
reach the list a week ago, but nevertheless ? thanks all for your
extremely helpful responses on this.  By far the most convenient option
(if your distribution supports it) is indeed to

  apt install vim-redact-pass

.. after which a security message pops up every time you invoke 'pass
edit', letting you know that the relevant leaky features have been
disabled.

Conrad