-
New Feature
-
Resolution: Fixed
-
Major
-
None
-
-
2.85
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes ").
In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example:
// Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } }
Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead:
node {
withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) {
sh 'echo $PASSWORD'
}
}
This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage.
- causes
-
JENKINS-64185 GerritTrigger.setTriggerOnEvents() expects class PluginGerritEvent but received class workflow.cps.DSL$NamedArgsAndClosure
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-
- relates to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
[JENKINS-63254] Warn against using secrets in groovy strings
| Description |
Original:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } {code} Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' echo "username is $USERNAME" } } {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
New:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } {code} Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
| Description |
Original:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } {code} Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
New:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } {code} output: {code:bash} [Pipeline] { [Pipeline] withCredentials Masking supported pattern matches of $USERNAME or $PASSWORD [Pipeline] { [Pipeline] sh + echo s28892cr3t s28892cr3t [Pipeline] } [Pipeline] // withCredentials [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS {code} Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} output: {code:bash} [Pipeline] { [Pipeline] withCredentials Masking supported pattern matches of $USERNAME or $PASSWORD [Pipeline] { [Pipeline] sh + echo **** **** [Pipeline] echo username is $USERNAME [Pipeline] } [Pipeline] // withCredentials [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
| Description |
Original:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } {code} output: {code:bash} [Pipeline] { [Pipeline] withCredentials Masking supported pattern matches of $USERNAME or $PASSWORD [Pipeline] { [Pipeline] sh + echo s28892cr3t s28892cr3t [Pipeline] } [Pipeline] // withCredentials [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS {code} Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} output: {code:bash} [Pipeline] { [Pipeline] withCredentials Masking supported pattern matches of $USERNAME or $PASSWORD [Pipeline] { [Pipeline] sh + echo **** **** [Pipeline] echo username is $USERNAME [Pipeline] } [Pipeline] // withCredentials [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
New:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } {code} output: {code:bash} [Pipeline] { [Pipeline] withCredentials Masking supported pattern matches of $USERNAME or $PASSWORD [Pipeline] { [Pipeline] sh + echo s28892cr3t s28892cr3t [Pipeline] } [Pipeline] // withCredentials [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS {code} Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} output: {code:bash} [Pipeline] { [Pipeline] withCredentials Masking supported pattern matches of $USERNAME or $PASSWORD [Pipeline] { [Pipeline] sh + echo **** **** [Pipeline] } [Pipeline] // withCredentials [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
| Description |
Original:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } {code} output: {code:bash} [Pipeline] { [Pipeline] withCredentials Masking supported pattern matches of $USERNAME or $PASSWORD [Pipeline] { [Pipeline] sh + echo s28892cr3t s28892cr3t [Pipeline] } [Pipeline] // withCredentials [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS {code} Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} output: {code:bash} [Pipeline] { [Pipeline] withCredentials Masking supported pattern matches of $USERNAME or $PASSWORD [Pipeline] { [Pipeline] sh + echo **** **** [Pipeline] } [Pipeline] // withCredentials [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
New:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
| Link |
New:
This issue relates to |
Reinhold Füreder
made changes -
| Description |
Original:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
New:
It is possible to accidentally leak secrets, such as credentials, when using groovy strings (i.e. double quotes "). In a groovy string, any secrets in the string will be interpolated by groovy before being processed for further use. This can allow other processes to accidentally expose the secret. For example: {code:groovy} // Terribly obvious example node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh "echo $PASSWORD" } } {code} Any secrets should be used in single quotes so that they are expanded by the shell as an environment variable instead: {code:groovy} node { withCredentials([usernamePassword(credentialsId: 'bobid', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh 'echo $PASSWORD' } } {code} This behavior is already discouraged against in the credentials-binding docs as well as various places, but it would be Ideal to have some mechanism that warns against this usage. |
That was actually a mistake as I meant to only prepare the changelog for a 2.85 release. Will correct the changelog.
That said, the commit only happened an hour ago, so it is fair to say that these ticket may not be updated instantaneously the moment of release/merge.
| Released As | New: 2.85 | |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Fixed but Unreleased [ 10203 ] |
According to https://github.com/jenkinsci/workflow-cps-plugin/blob/master/CHANGELOG.md this nice feature has allegedly already been released? But ticket status is still "Open"?