New project fork?

[Tim Rice]

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.