[pass] copying usernames and urls

[Matthieu Weber]

On Tue 29.04.2014 at 10:06:28PM +0200, Jason A. Donenfeld wrote:
> On Tue, Apr 29, 2014 at 8:44 PM, Matthieu Weber <mweber at free.fr> wrote:
> > Because these fields are closely related and keeping them in separate
> > files, even though it is technically possible, makes no sense imho.
> 
> While I see several reasons why using the filesystem might not be
> desired, what you've said completely fails to present an argument even
> remotely compelling. See if you can flesh this out a bit more.

- It uses directories to represent both the credentials (login,
password, url) for a given service and groups of such credentials which
are logically different concepts.

- It clutters the tree with a lot of repeating names. Using tree -d as
you suggested is not a generic solution, since it assumes that filenames
contain no meaningful information, thus restricting the user's choices
for naming/organizing data in the filesystem.

- It forces to handle separately pieces of data that one wants
to keep close together (e.g., renaming the directory requires 3 separate
git mv operations which need to succeed atomically). This in turn requires a
specific tool to ensure the atomicity of the operation, or force the
user to manually handle multiple files, leaving the opportunity to make
mistakes.

- It still imposes a given format to the data since you still have a
key-value structure (filename being the key, file content being the
value). And it's actually more complicated to have multivalued fields
(since you don't want to impose any format, you must give the
possibility to have such a possibility even though I'm not sure if it's
really useful), unless you put multiple values in a given file, but then
you must choose a format to separate those multiple values (newlines as
a separator is a logical choice, it is a file formatting choice nonetheless).

- It exposes the structure of the credentials (i.e, an observer of the
repository can see what are the credentials composed of, even if the
values are encrypted).

Pass already makes assumptions about the format of the file:
line-separated data, first data is the password. It could simply ignore
whatever comes after the first newline, and rely on third-party programs
(frontends, plugins, whatever) to interpret the rest of the file
whichever way the user likes it. Which is exactly what pass currently
does.

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.

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)" (_)-(_)