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 <[email protected]> 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. >> > _______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
