ensure all credentials are masked in output logs

[clemensutschig]

there is still cases where credentials may not be masked (e.g. thru the ods-context).

[renedupont]

so far I only found the snyk auth token in the console output, what other credentials did you see?

[michaelsauter]

I think also the Nexus credentials can be exposed as they are not read via withCredentials :(

[renedupont]

@clemensutschig @michaelsauter
After looking a bit into it the only quick fix I found so far without any changes on the user side would be to use 'set +x' in the shell cmd, e.g:

script.sh(
  script: """
            set +x
            snyk auth ${authCode} | tee -a ${reportFile}
          """,
  returnStatus: true,
  label: "Authenticate with Snyk server"
)

...that way it is not displayed in the output. It looks then like this:

[Pipeline] sh (Authenticate with Snyk server)
set +x

Your account has been authenticated. Snyk is now ready to be used.

btw. I found in Jenkins that if you open a build and click on the right side 'Pipeline Steps' (instead of 'Console Output') that all credentials are visible there in clear text... even the ones that are used within withCredentials.
Any thought on this if this is critical or not?

[michaelsauter]

I think the most important thing is to avoid accidental credentials leakage. Therefore I'm ok with them being visible outside the build logs.

Regarding Snyk, it makes sense to do set +x, however we could also do the automatic transformation to a secret ... maybe we do set +x now because it is easy, and then do the secret in a next step.

[renedupont]

Yes I was thinking the same regarding the next steps...

but I just discovered that if you use Jenkins in the blue ocean view, it is all there in clear text :(
even when withCredentials was used.

[michaelsauter]

@renedupont wow. is that a known bug with the credentials plugin and/or blue ocean? that sounds like something the Jenkins community would try to fix, no?

[renedupont]

I don't know yet, this needs further investigation, but it looks like as if the blue ocean view is basically what you can see in the classic view if you click on 'Pipeline Steps'

[renedupont]

another idea that @stitakis told me about is to write the command into a file and execute it from there.
For example I tried this

    script.writeFile file: 'snykauth.sh', text: 'snyk auth ' + authCode + ' | tee -a ${reportFile}'
    script.sh(
        script: """
          ls -l snykauth.sh
          chmod +x snykauth.sh
          ./snykauth.sh
        """,
      returnStatus: true,
      label: "Authenticate with Snyk server"
    )

and it results in the log as:

[Pipeline] writeFile
[Pipeline] sh (Authenticate with Snyk server)
+ ls -l snykauth.sh
-rw-r--r--. 1 default 1009280000 69 Apr  6 19:46 snykauth.sh
+ chmod +x snykauth.sh
+ ./snykauth.sh

Your account has been authenticated. Snyk is now ready to be used.

I could not see it either in the ocean blue view. We could write a groovy method in /vars folder that encapsulates this, but for me this still looks like a workaround.

I am considering to take a look at https://jenkins.io/doc/pipeline/steps/mask-passwords/ soon. If this works maybe we could integrate this into the jenkins image.

[renedupont]

@michaelsauter I think I found out why the credentials are not masked when we use withCredentials... we use triple-double-quotation marks instead of triple-single-quotation marks in the sh call.
Unfortunately, when using the single marks ('''), variables are not interpolated and something like USERPASS.replace(...) does not work that way when using '''. I tried out a lot of variants to still get it right that way but no luck yet.

[michaelsauter]

@renedupont Why is triple-double-quotes an issue? Do you have a reference?

[renedupont]

I tried it out because of the examples given here: https://jenkins.io/doc/pipeline/steps/credentials-binding/

[clemensutschig]

partially fixed by #329