[pass] copying usernames and urls

[Brian Shore]

On Tue, May 6, 2014 at 12:35 PM, Matthieu Weber <mweber at free.fr> wrote:
> Also we loose the fact that "pass" without argument is equivalent to
> "pass show". This is arguably a minor problem.

I didn't even know this was possible until I was adjusting the code
for my proof of concept, I've never used it.  Also, tab completion
fails when no command is given, which makes the use case pretty
awkward.

> 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.

I think the extra hurdles would discourage people from making
extension scripts, too much hassle.

> 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?

I'm not in favor of renaming pass.  I would prefer to have, say,
frontend contrib scripts in /usr/local/libexec/pass/ and just call one
as a shell alias or function, "pass" -- of course, this would require
that the scripts use a full path to call core pass.

> 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?

I use something similar but in YAML.  Not all fields are always
present, of course.
password
---
username: ...
password: ...
account_number: ...
security_questions:
  a: b
  c: d
...


I think people should be able to choose formats that suit them, but I
agree that core pass functionality should not care about this.  If we
did take the "extension scripts" route, it would even be easy to
replace the "show -c" behavior.  On OSX, this could be something like
$HOME/bin/pass-clip containing a command such as

    pass show "$1" |head -n 1 |pbcopy

And if that conflicts with someone's chosen file format, they can use
a different pass-clip from contrib/ or write their own.


-- 
Brian Shore
Senior Systems Engineer, Security Architect
Network Redux, LLC
5200 SW Macadam Ave Ste 450
Portland, Oregon 97239
Desk:  503-274-9905 x503