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