Open alex-harvey-z3q opened 7 years ago
It looks like the "feature" is documented in the README, but not in the usage message.
A workaround to this is to pass your secret via STDIN
. For example
$ echo -n "@4=saCD0nF" | credstash put -v 1 'jenkins_ad_bind_pass' -
*Thanks to @alexharv074 for catching a mistake in this workaround, fixed now.
@alexharv074 mentioned in #20 that the workaround would work for him
Does anyone have any thoughts on the likelihood that others would encounter this issue? I guess my unstated assumption was that the incidence of people passing secrets/passwords as command line arguments to credstash would be low (due to the insecurity of doing so) but maybe I'm mistaken and that's a common use case and others will also encounter secrets that begin with the @
character.
We use a Jenkins password parameter to get a secret from a user, and the Jenkins build step then passes that secret to the credstash command line. Jenkins takes care of redacting the secret in the logs for us, so it's quite secure. I assume that others will encounter this issue, sooner or later.
It should be noted that the workaround above adds a newline as part of the secret. It should be:
$ echo -n "@4=saCD0nF" | credstash put -v 1 'jenkins_ad_bind_pass' -
Alternatively, you could use the printf
command:
$ printf @4=saCD0nF | credstash put -a 'jenkins_ad_bind_pass' -
I also ran into this issue with a -
to begin the password, as it was autogenerated elsewhere. Workaround worked great though.
How would the workaround work with contexts? I tried to echo -n..... with contexts in it, doesnt work
As a result of https://github.com/fugue/credstash/issues/19 it seems that it is now impossible to add secrets that begin with
@
:The root cause is that the "@" is interpreted by credstash as denoting a file name argument. As a result, there seems to be no way to add an actual secret if it begins with an "@" character.