[pass] ***UNCHECKED*** Re: [Feature Request] Add a `--raw` option to `pass ls`

[Linden Krouse]

If the choice of the maintainers of pass is to never change the underlying
file structure for any reason whatsoever, than I suppose we don't need a
`pass ls - - raw`. The goal was to decouple the way pass stores its data
from other programs' usage of that data, which would encourage future
development, and to provide common functionality currently implemented
outside of pass as to avoid duplicating code specific to pass in other
programs and scripts.

I would argue the maintenance cost of this feature replaces the hidden
maintenance cost of keeping any file system interactions exactly the same
for the rest of pass's lifetime, and having to work around such a
limitation for any future patches. The only scenario in which this feature
would be updated is one where the underlying storage of passwords was
changed, which would be impossible otherwise without breaking the currently
recommended way to interact with pass's passwords in scripts.

After a bit more thought, it occurs to me that pass seems to be mostly a
user interface for managing passwords stored in a file system and not a
password manager itself to keep with the Unix philosophy. However, it still
seems silly to provide usability features like `pass git` and not others
for philosophical reasons.

Lastly, while I can see the reasoning to not wanting to accept new
option-providing feature patches, from a development standpoint, code
relating to options could be separated into its own files, in its own
directory. Although I haven't taken a look at pass's source, the usual
solution is to refactor code to alleviate any unmanageable clutter.

P. S. I'm not trying to force an argument here, but I want to be certain
there won't be major breaking changes down the line for any of my scripts
using pass.

On Nov 10, 2016 9:26 AM, "Kenny Evitt" <kenny.evitt at gmail.com> wrote:

Alternatively, Pass could simply commit to its current implementation of
using the filesystem as it does and that would resolve any potential future
incompatibility issues just as well. If we were voting, that's what I would
vote for.

The Pass website <https://www.passwordstore.org/> currently seems to
support such an interpretation:

> Password management should be simple and follow Unix philosophy
<https://www.wikiwand.com/en/Unix_philosophy>. With pass, each password
lives inside of a gpg encrypted file whose filename is the title of the
website or resource that requires the password. These encrypted files may
be organized into meaningful folder hierarchies, copied from computer to
computer, and, in general, manipulated using standard command line file
management utilities.

Every program that uses the filesystem doesn't need to provide an API with
its own abstraction over the filesystem. Anything that wants to can just
use the filesystem directly!



Even assuming that the existing patches are complete and without bugs,
there's documentation too both in Pass itself, the Pass man page, and the
Pass website, all of which might need or warrant being updated. But then of
course there's the cost of maintaining that feature indefinitely too.
Please be considerate in *expecting *someone else to commit to doing that
work for you. I'm not claiming you are, but you certainly seem to be
minimizing the amount of potential work that needs to be done.

If we're properly accounting for all of the effort involved by everyone
anywhere, the easiest thing for you to do would be to just maintain your
own private fork of Pass with whatever patches you want to incorporate. I'm
considering doing that myself precisely because writing long commands or
maintaining separate scripts is a 'hassle'. Tho of course maintaining a
fork is a 'hassle' too. Trade-offs abound!

On Thu, Nov 10, 2016 at 2:45 AM, Linden Krouse <ztaticnull at gmail.com> wrote:

> While you could read the password directory directly, wouldn't it be
> better for future compatibly to have pass print the raw key names? If pass
> ever changes the way it stores it's passwords, every script relying on the
> current layout will break. Also, `{ cd ${PASSWORD_STORE_DIR:-$HOME/.password-store};
> find -type f -name '*.gpg' -printf "%P\n" | sed 's/\.gpg$//'; }` is much
> longer and more difficult to read than `pass ls --raw` which
> describes exactly what is being done. Having to do this repeatedly, or
> create and store a script specifically to do this just adds more hassle to
> pass.
>
> Lastly, at least one other person has written a patch to add this feature
> so it wouldn't take any additional effort to implement, as the work as
> already been done.
>
> On Wed, Nov 9, 2016 at 3:43 PM, Lenz Weber <mail at lenzw.de> wrote:
>
>> Actually, if you want to write a software to use that ouput this should
>> be quite intuitive for you, yes.
>>
>> Even simpler would be
>>
>> { cd ${PASSWORD_STORE_DIR:-$HOME/.password-store}; find -type f -name
>> '*.gpg' -printf "%P\n" | sed 's/\.gpg$//'; }
>>
>> just don't forget the braces.
>>
>> Am 09.11.2016 um 21:22 schrieb Tobias Girstmair:
>> >> TL;DR We don't need `pass ls --raw` because we have `ls -1`
>> >
>> > well, `ls -1` doesn't exactly provide a recursive output. this could be
>> done with a convoluted tree statement (see my patch) or this find one
>> (which isn't simpler, and I haven't checked for symlinks or other strange
>> things):
>> >
>> >
>> >     find ${PASSWORD_STORE_DIR:-$HOME/.password-store} -type f -name
>> '*.gpg'|sed 's|^${PASSWORD_STORE_DIR:-$HOME/.password-store}/||'|sed
>> 's/\.gpg$//'
>> >
>> >
>> > intuitive, isn't it? ;-)
>> >
>> > Another use case is an interactive user, who wants to copy-paste a line
>> of the `pass ls` output into `pass show`.
>> >
>> > -- Tobias
>> > _______________________________________________
>> > Password-Store mailing list
>> > Password-Store at lists.zx2c4.com
>> > http://lists.zx2c4.com/mailman/listinfo/password-store
>>
>>
>>
>> _______________________________________________
>> Password-Store mailing list
>> Password-Store at lists.zx2c4.com
>> http://lists.zx2c4.com/mailman/listinfo/password-store
>>
>
>
>
> --
> - Sent from my microwave oven
>
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20161110/a95595b7/attachment.html>