Support passing multiple arguments to provider

[raphink]

Gopass supports subvalues when the path is followed by a space, for example:

gopass /path/to/value subkey

When the value stored at /path/to/value is a YAML document, this will return the subkey of that YAML document.

However, summon passes the entire value as a single argument to the provider, so:

FOO: !var /path/to/value subkey

is passed as:

gopass "/path/to/value subkey"

which doesn't work.

Describe the solution you would like

One option is to use a wrapper script for gopass to split the arguments before passing them to gopass. However, it would be cleaner if summon would call gopass and pass the arguments one by one.

Describe alternatives you have considered

The wrapper script is an alternative solution which works, but is not as elegant:

gopass $(echo "${@}")

[sgnn7]

Hmm... I think we may need to figure out how to specify a split variable maybe since I think at least one provider (conjur) allows white spaces as part of the variable name. Your wrapper may work but it's possible that we can add a meta-tag to hint summon about this provider capability.

[BradleyBoutcher]

Hi @ralphink,

Thank you again for using summon and reaching out to us! I did some digging through the existing documentation provided by gopass to better understand your use case.

According to the gopass documentation on summon, they don't list any use cases where one may need to specify a subkey. It seems that gopass only supports subkeys when attempting a "fuzzy search", i.e. when the user is unaware of the exact path to the secret.

However, I may be misunderstanding something or missing a piece of documentation. Would you be able to provide more information on your specific use case?

Edit: Upon further research, I see your issue. gopass stores each password in its own file as a value with a key. My apologies for misunderstanding!

Without a subkey:

▶ gopass show test/foo/bar password
test

With a subkey:

▶ gopass show test/foo/bar         
Password: test

@sgnn7 may be able to weigh in on this better than I, but I believe the issue lies with gopass rather than summon. Since gopass uses files for storage, a potential workaround would be to retrieve your passwords with the !file identifier rather than !var, then extract the value for the appropriate key. Alternatively, you can write a shell script as a provider that splits the path and subkey and strips the quotation marks before calling gopass.

[raphink]

Thanks for your comment @BradleyBoutcher. I think you meant to invert the two examples (with and without subkey).

We do use the !file flag at times, even with subkey in fact. For example, if I have one entry (file) in gopass which stores multiple OpenSSL credentials (key, cert, cacert), then I'll use something like this:

---
CERT: !var:file path/to/secret cert
KEY: !var:file path/to/secret key
CACERT: !var:file path/to/secret cacert

so I get 3 variables pointing to temp files containing the credentials.

[ckolumbus]

FYI: I created a PR gopasspw/gopass#1438 to provide a dedicated summon provider with gopass as the output format is not (always) following the summon protocol. It's more strict but with respect to key searching but functionality specific to summon can now be implemented without affecting the standard gopass behavior. Maybe you can leave some comments int the PR if there's a possibility to better support your use-case from the gopass provider side.

[sgnn7]

@raphink / @ckolumbus After further consideration, I believe that some providers are explicitly fine (and depend on) passing spaces as-is so the linked PR (#156) cannot get included in its current state as it will have cascading effects on unknown number of providers and users for a subjectively smaller slice of use cases.

Given our previous discussions on this, I think we could still make this work natively by using an explicit --multi-arg (or --split-on-spaces or something else) CLI flag and splitting the string for the provider if that flag is enabled. Let us know if that works for you and if the work will continue on that PR from your side so that we can figure out how to manage resources/timelines on implementing this. In the meantime, we will try to get #149 done so that there's at least some interim way to run summon + gopass but I agree that we could support this natively with not a lot of effort and help out your UX.

PS: It's always great to see that there's good discussion on improving summon 👍

[boazmichaely]

Published in CyberArk Aha! idea portal