[pass] copying usernames and urls

[Matthieu Weber]

On Tue 06.05.2014 at 08:50:00AM -0700, Brian Shore wrote:
> On Thu, May 1, 2014 at 3:15 PM, Brian Shore <brian at networkredux.com> 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 - mweber at free.fr              (~._.~)
  ( ? )                http://weber.fi.eu.org/                    ( ? ) 
 ()- -()          public key id : 0x85CB340EFCD5E0B3             ()- -()
 (_)-(_) "Humor ist, wenn man trotzdem lacht (Otto J. Bierbaum)" (_)-(_)