<Is everybody using something similar or is someone using a radically <different format, that may justify implementing different frontend tools?
While I usually follow the passff format, I see a potential usecase for pass to store: keys, certificates, cryptocurrency, and contact lists. address public-key:1CCGUooHZyrS1nwRwpZAXQbYk93Mo1197i private-key:5JYEnqde7kZ2ynH8eRMHjbAuznKwYMHfYBH2wVnUKR9YTJS**** You guys made some compelling arguments for keeping pass simple. I also see that pass has a lot of potential for growth. It makes me nervous when I hear talk of taking features away. What if a GUI fails? Pass will still have a simple CLI, right? On Tue, May 6, 2014 at 3:35 PM, Matthieu Weber <[email protected]> wrote: > 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 > -- For secure messaging, contact me on Jitsi <https://jitsi.org/>.
_______________________________________________ Password-Store mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/password-store
