Details
-
New Feature
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
Description
In a pipeline script when a developer uses `withCredentials` credentials are hidden in logs to reduces the chance of accidental disclosure (see JENKINS-38181)
When using a password parameter in a job the same concept should be applied to it and it should be impossible to display its value in logs
A work-around is to use the MaskPasswordsBuildWrapper but it has to be manually done (and it's a bit crappy)
node {
wrap([$class: 'MaskPasswordsBuildWrapper', varPasswordPairs: [[password: "${myPassword}", var: 'PASSWORD']]]) {
println myPassword
sh 'echo "Hello World ${myPassword}"'
}
}
.
Attachments
Issue Links
- relates to
-
JENKINS-27392 API to decorate console output
-
- Resolved
-
-
JENKINS-57717 showRawYaml doesn't work inside podTemplate
-
- Resolved
-
-
-
- Open
-
-
-
- Open
-
-
-
- In Progress
-
Activity
proposed a mechanism by which it could be implemented
This is actually possible now via TaskListenerDecorator, I think.
Olivier Lamy
added a comment - this plugin exists https://github.com/jenkinsci/redacted-password-parameters-plugin
Olivier Lamy
added a comment - this plugin exists https://github.com/jenkinsci/redacted-password-parameters-plugin Indeed it looks that way.
The design of the password parameter type built into core is just not ideal. Just as we needed to create a new plugin to handle file parameters sanely, it may be time for a redesigned password & credentials parameter type aligned with JENKINS-27398 and solving things like JENKINS-36007. For example, submitting a secret to a build (as a parameter, or via input) would cause a StringCredentials to be temporarily available only in that build (or at least job), with the environment variable being set to the (random) id, so if you had a parameter named DEPLOY_KEY you could write something like
withCredentials([string(credentialsId: DEPLOY_KEY, variable: 'DEPLOY_KEY_VAL')]) { sh './deploy --key=$DEPLOY_KEY_VAL' }
binding the secret just where you actually need it and getting masking for free; or the credentials could be passed to a step without needing the awkward idiom used by credentials parameters:
deploy server: '…', credentialsId: DEPLOY_KEY
Ideally you could also pass the secret along to a downstream build with the build step, etc., all without ever having the plaintext be present in logs, build metadata, or the like. (Even exposing a Secret.encryptedValue is not necessarily safe: SECURITY-266.)
I've been meaning to comment on a cryptographic design for this, but I was refraining until I had a more succinct way to describe it. Then I remembered that GitHub Actions implement this almost exactly the way I'd recommend doing it (but integrated with Jenkins APIs instead):
- https://docs.github.com/en/actions/reference/encrypted-secrets
- https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes
- Unfortunately, this is a native library. Looking at their third party bindings, this project looks the most active: https://github.com/muquit/libsodium-jna
- Alternatively, the algorithms needed to implement this are all in Bouncycastle, but not as a unified API. See https://stackoverflow.com/a/42456750 for a similar glue idea with smaller libraries.
- Or a sealed box can be created using ECDH, SHA-2, and AES/GCM if FIPS compliance is necessary.
HOSTING-679 claims to implement something like this.