summon
summon copied to clipboard
Support passing multiple arguments to provider
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 "${@}")
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.
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.
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.
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.
@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 👍
Published in CyberArk Aha! idea portal