Get field value for command show and option -c

[Andrew Stryker]

Adrien Horgnies <ah at fita.dev> wrote on 2024-Feb-28:
> Hi,
> 
> The website https://www.passwordstore.org/ suggests to organize data like this:
> 
> > Yw|ZSNH!}z"6{ym9pI
> > URL: *.amazon.com/*
> > Username: AmazonianChicken at example.com
> > Secret Question 1: What is your childhood best friend's most bizarre superhero fantasy? Oh god, Amazon, it's too awful to say...
> > Phone Support PIN #: 84719

The perspective of the maintainer is that this pattern is a suggested
convention. The only hard requirement is that actual password is on the
first line of the file.

> However, it's impractical to use if you want to copy any information there,
> as you only need the thing on the right side of the colon.
> 
> I'd like to suggest the following feature for the command "show" and
> option "-c":
> - An non-numerical value is treated as a field key to search for
> - Instead of copy / qrencode the full line, it processes the value
> next to the key
> 
> Here's how it would work:
> 
> ```console
> $ pass foo
> foo
> user: bar
> pin: 1234
> stuff: spam
> $ pass -cuser foo && wl-paste
> Copied foo to clipboard. Will clear in 45 seconds.
> bar
> $ pass -cpin foo && wl-paste
> Copied foo to clipboard. Will clear in 45 seconds.
> 1234
> ```
<snip>

I typically do something like:

    pass foo | awk '/^bar:/ { print $2 }' | xsel -b

or

    secret=$(pass foo | awk '/^bar:/ { print $2 }')

if I am in script.

There are a few trade-offs here. Your proposal increases the complexity
of the file structure, the user interface, and the coded base. Not by a
lot, but every command and requirement adds to amount a user needs to
know in order to effectively use the application. Every line increases
the effort required to maintain the code.

The benefit is that you make a use pattern easier. There are already
ways to accomplish the intended effect. Your approach trades additional
complexity or user simplicity. Making the process for managing secret
information easier is a huge benefit.

The question becomes, is this use case prevelant enough to warrant your
proposal?

Have you considered making this a pass extension? Pass supports third
party extensions (e.g., https://github.com/tadfisher/pass-otp). The
drawback is that you would not be able to directly extend the "show"
command in a logical way, which your proposal does.

I suggest coding your approach as an extension:

  1. The maintainer (Jason) is very inactive. I have not seen him post
     to this list in quite some time. Getting your proposal accepted and
     merged requires his participation or forking the project.

  2. The case that the benefit outweighs the cost is not entirely clear.
     Maybe yes, maybe no from my perspective. Making a strong argument
     here will be hard.

  3. Following the extension pattern should be possible. And if it is
     a popular extension, then you will have a strong case for moving it
     to the core.

I hope you find this useful. Best of luck.

Andrew