[pass] copying usernames and urls

[John Fetsko]

<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 <mweber at free.fr> 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 <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)" (_)-(_)
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store
>



-- 
For secure messaging, contact me on Jitsi <https://jitsi.org/>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20140506/a5bb9238/attachment.html>