New project fork?

Nicolas Graves ngraves at ngraves.fr
Thu May 22 04:52:36 UTC 2025


-------------------- 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


More information about the Password-Store mailing list