On Tue 06.05.2014 at 08:50:00AM -0700, Brian Shore wrote: > On Thu, May 1, 2014 at 3:15 PM, Brian Shore <[email protected]> wrote: > >> I would even go further, as I explained elsewhere already: remove from > >> pass the capability to copy stuff to the clipboard and the capability to > >> generate a password, and delegate this to a frontend (I'm not sure what > >> to do with the edit feature, it doesn't belong in this core-pass, but I > >> would still keep it as an emergency-repair tool). Just keep the > >> encryption and file-manipulation features (including git): pass thus > >> becomes a tool that manipulates files, shows the content of a file, > >> and allows to replace the whole content of a file at once, wihtout > >> making *any* kind of assumption about its content. For real, this time. > > > > I don't have that thread in front of me, so I'll hijack this one. > > We could make it very easy to extend pass with external tools by > > copying git -- any subcommand (cp, mv, find, etc) that isn't in the > > core is sought in the PATH as pass-$subcommand. So if you want a > > "pass find" command, just create a script named pass-find somewhere > > in your $ PATH. > > > > We can share info like the prefix by exporting to the environment. > > We keep the core small, we get a consistent interface. > > If anyone is curious, the patch to enable this is small and looks > something like the below. Exporting some additional variables might > be helpful at some point, this is really just a (working) proof of > concept. > > I've tested the below with a trival script that just printed a few > lines of output to announce that it had been called. > > This could allow the core of pass to remain small and allow extension > scripts to be called transparently. One detractor from this approach > is that info about extension scripts would not appear in pass' usage > info.
Also we loose the fact that "pass" without argument is equivalent to "pass show". This is arguably a minor problem. But what I like with this approach is that it's possible to put a "pass-foo" tool in $HOME/bin for home-made commands, without having to meddle with the system-wide pass installation. An alternative would be to force placing all these extension commands in one (or more) well-known locations and call "pass-foo help" on each of them in sequence when the user calls "pass help". This would solve the usage info problem, but make quick-and-dirty home-made extensions harder to install. Is anyone in favour of the opposite approach: rename "pass" to "passcore", and write "pass", "menupass", "xyzpass"... frontends that use passcore for core features, and otherwise implement whatever commands the user prefers? One advantage I see to this is that there would be one frontend with a set of commands that expects a given data format inside the password file, and possibly another frontend with a similar (or different) set of commands that expects possibly another data format inside the password file. Different developers/maintainers, different users, with different needs, would then use one tool or another, depending on what file format they prefer. That would mean possibly duplicating commands between those tools, but it also enforces one file format within one tool, while keeping passcore format-agnostic. Does anyone have a use-case for this approach? Or is there really a need for multiple file formats? What do you use in your password files? I personally use the following: - password on the first line - RFC-822 style key/values on the following lines + username + email + login (mostly to be compatible with the Firefox plugin) + url + security questions and corresponding answers Is everybody using something similar or is someone using a radically different format, that may justify implementing different frontend tools? Matthieu -- (~._.~) Matthieu Weber - [email protected] (~._.~) ( ? ) http://weber.fi.eu.org/ ( ? ) ()- -() public key id : 0x85CB340EFCD5E0B3 ()- -() (_)-(_) "Humor ist, wenn man trotzdem lacht (Otto J. Bierbaum)" (_)-(_) _______________________________________________ Password-Store mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/password-store
