[PATCH] Added way to insert files, modified help accordingly. Added -h as additional help parameter
alexandre at pujol.io
Sun Jan 29 13:47:31 CET 2017
Jason wrote a simple example of extension in this ML:
$ echo 'echo I am an extension and here are my arguments: $@; echo and
here are my variables $(set)' >
$ chmod +x ~/.password-store/.extensions/test.bash
$ pass test hello world
For more complex examples you can check the two extensions I made: , .
The extensions directory can be:
- PASSWORD_STORE_EXTENSIONS_DIR (default ~/.password-store/.extensions/
for user extension)
- /usr/lib/password-store/extensions for system extension
And you need to enable extension with PASSWORD_STORE_ENABLE_EXTENSIONS=true
On 29/01/17 00:44, HacKan wrote:
> I don't entirely agree with all you said, but implementing this as a
> user extension sounds like an awesome idea! I'm doing it :D
> Any guidelines or whatsoever? How should extensions should be written?
> BTW, having a curated list for such extensions is a must have, like
> KeePass does.
> On 01/28/2017 05:12 PM, David A. wrote:
>> On Fri, 27 Jan 2017 15:02:45 -0300, HacKan <hackan at gmail.com> wrote:
>> I don't think you should have added in the '-h' option within this
>> patch simply because it's unrelated.
>> I also think this error message should include the file name:
>> die "File is not valid."
>> It's all too easy to type something like "pass insert US Bank" and
>> forget to escape or quote the space and then wonder why your error
>> message is happening.
>> Overall this is a fairly reasonable attempt at the solution. However,
>> I think it requires more pause for thought. This patch expands the
>> official scope of pass from being strictly a password only store to a
>> general purpose encrypted store for any and all random files. Heck,
>> today it doesn't even officially support usernames in any meaningful
>> This change in direction opens a huge can of worms. The next obvious
>> need would be to have pass launch whatever programs are needed to view
>> whatever random files are stored. That is a complete nightmare when
>> you consider the cross-platform nature of pass. Then there's the
>> security implications of how to launch the decrypted file, where it
>> might be stored while in use, will it be removed when done, etc.
>> Personally, I do like the idea of this patch and what it provides, but
>> I don't think that pass should accept the overreaching implications of
>> The fact is, the functionality of this patch already exists today in a
>> slightly less obvious way. That was already demonstrated in your
>> earlier thread. It's easy enough to have your own external script
>> that makes this process seamless. With the new extension capability
>> that external script can now appear to be an official pass subcommand.
>> That's the route I think you should go.
>> On that note, I think Jason should add a section to the web page for
>> browsing and downloading user written extensions. Though I'm not sure
>> the extension functionality is fully fleshed out yet.
>> [the following not directed at HacKan]
>> Too many people think that every little function they dream up needs
>> to be built in to pass. They forget that pass is intended to be a
>> simple scriptable piece of the UNIX CLI tool chain which opens vast
>> possibilities for extending the functionality.
More information about the Password-Store