[PATCH] Added way to insert files, modified help accordingly. Added -h as additional help parameter

[Alexandre Pujol]

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)' >
~/.password-store/.extensions/test.bash
$ chmod +x ~/.password-store/.extensions/test.bash
$ pass test hello world
...

For more complex examples you can check the two extensions I made: [1], [2].

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

[1] https://github.com/roddhjav/pass-update
[2] https://github.com/roddhjav/pass-import

Good luck,
Alex


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.
> 
> Cheers!
> 
> 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
>> way.
>>
>> 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
>> it.
>>
>> 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.
>>
>