Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-47101

Pipeline withCredentials step does not mask step descriptions for variables with the same name as existing system variables

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      There seems to be an issue with the Pipeline step withCredentials and how it masks variables.

      It seems that when a variable name already exists in the current environment, the step description masking is skipped and the variables are rendered as clear text.

      In the console log, the steps are masked correctly (the step description is not included anyway).

      I first observed this happening in the Blue Ocean UI as part of a script pipeline job.

      As a workaround, using a script seems to hide the step description (for shell cmds at least).

      Pipeline code to reproduce:

      pipeline {
          agent any
          
          stages {
              stage('test withCredentials bug'){
                  steps {
                      withCredentials([usernameColonPassword(credentialsId: 'withCredentialsBug', variable: 'USER')]) {
                          sh "echo '$USER'"
                          sh './user.sh'
                      }
                      
                      withCredentials([usernameColonPassword(credentialsId: 'withCredentialsBug', variable: 'USRPWD')]) {
                          sh "echo '$USRPWD'"
                          sh './user.sh'
                      }
                  }
              }
          }
      }
      

      user.sh helper script exists in the workspace:

      echo "\$USERPWD = $USRPWD"
      echo "\$USER = $USER"
      

      I've attached some screenshots below.

        Attachments

          Issue Links

            Activity

            Hide
            catalin_cretu Catalin Cretu added a comment - - edited

            I've had a look around existing issues, but I couldn't really find this sort of bug. I'm not entirely sure about the priority either.

            Show
            catalin_cretu Catalin Cretu added a comment - - edited I've had a look around existing issues, but I couldn't really find this sort of bug. I'm not entirely sure about the priority either.
            Hide
            jglick Jesse Glick added a comment -

            Due to the hack in ArgumentsActionImpl.SAFE_ENVIRONMENT_VARIABLES which tries to guess which things are secrets but does not really know.

            What I recommended to Sam Van Oort when he initially wrote this code was that we should rather get some coöperation from plugins which define secret environment variables. For freestyle projects we have getSensitiveBuildVariables but there is no Pipeline equivalent; and EnvVars has no way of marking secret values.

            One option would be to introduce a new API into core and have credentials-binding, mask-passwords, and workflow-cps all depend on it. This would be probably be some more structure in EnvVars, with the various merging/appending methods updated accordingly.

            Or, an explicit contextual object representing a Set<String> of secret variable names could be introduced into workflow-step-api, a lightweight dependency that credentials-binding already has. This would be trickier to use from mask-passwords, however, since MaskPasswordsBuildWrapper could no longer be a SimpleBuildWrapper—it would need to be split into a distinct Step.

            The least intrusive approach, at the expense of compile-time safety, would be to adopt a simple convention along the same lines as PATH+STUFF=/opt/stuff/bin. For example, if CredentialsBindingStep is defining USRPWD=s3cr3t, it should also define something like SECRET+USRPWD=true. Both variables would propagate through to nested scopes in the usual way, and then ArgumentsActionImpl could tell for sure that it should mask s3cr3t because it sees the environment variable SECRET+USRPWD.

            Show
            jglick Jesse Glick added a comment - Due to the hack in ArgumentsActionImpl.SAFE_ENVIRONMENT_VARIABLES which tries to guess which things are secrets but does not really know. What I recommended to Sam Van Oort when he initially wrote this code was that we should rather get some coöperation from plugins which define secret environment variables. For freestyle projects we have getSensitiveBuildVariables but there is no Pipeline equivalent; and EnvVars has no way of marking secret values. One option would be to introduce a new API into core and have credentials-binding , mask-passwords , and workflow-cps all depend on it. This would be probably be some more structure in EnvVars , with the various merging/appending methods updated accordingly. Or, an explicit contextual object representing a Set<String> of secret variable names could be introduced into workflow-step-api , a lightweight dependency that credentials-binding already has. This would be trickier to use from mask-passwords , however, since MaskPasswordsBuildWrapper could no longer be a SimpleBuildWrapper —it would need to be split into a distinct Step . The least intrusive approach, at the expense of compile-time safety, would be to adopt a simple convention along the same lines as PATH+STUFF=/opt/stuff/bin . For example, if CredentialsBindingStep is defining USRPWD=s3cr3t , it should also define something like SECRET+USRPWD=true . Both variables would propagate through to nested scopes in the usual way, and then ArgumentsActionImpl could tell for sure that it should mask s3cr3t because it sees the environment variable SECRET+USRPWD .

              People

              • Assignee:
                Unassigned
                Reporter:
                catalin_cretu Catalin Cretu
              • Votes:
                3 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: