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

Error "hudson.model.PasswordParameterValue.value expects class hudson.util.Secret" since 2.236

    • pipeline-build-step 2.13

      Hello,

      since Jenkins 2.236 I get the following error when trying to start a job from a job:

      org.jenkinsci.plugins.workflow.support.steps.build.BuildTriggerStep: java.lang.IllegalArgumentException: Could not instantiate {name=SERVER_SSH_PASSWORD, value=XXXXX} for hudson.model.PasswordParameterValue: java.lang.ClassCastException: hudson.model.PasswordParameterValue.value expects class hudson.util.Secret but received class java.lang.String
      

      The pipeline look like the following (shortened):

      pipeline {
          agent {
              label 'linux'
          }
          // options, environment
      
          stages {
              stage('Deploy Production') {
                  when {
                      anyOf {
                          buildingTag()
                      }
                  }
      
                  steps {
                      script {
                          if (env.TAG_NAME) {
                              dockerTag = "${env.TAG_NAME}"
                          } else {
                              dockerTag = "dev-${env.BRANCH_NAME}"
                          }
      
                          withCredentials([
                              usernamePassword(credentialsId: 'centos-root', usernameVariable: 'SERVER_SSH_USER', passwordVariable: 'SERVER_SSH_PASSWORD'),
                              usernamePassword(credentialsId: 'database-maintenance', usernameVariable: 'LIQUIBASE_USERNAME', passwordVariable: 'LIQUIBASE_PASSWORD')
                          ]) {
                              build job: 'otherproject/otherjob/master', parameters: [
                                  string(name: 'PROJECT_VERSION', value: "${dockerTag}"),
                                  string(name: 'PROJECT_ENVIRONMENT', value: 'production'),
                                  string(name: 'LISTEN_IP_NGINX', value: "172.21.240.14"),
                                  string(name: 'COMPOSE_ARGS', value: '-f docker-compose.yml'),
                                  string(name: 'SERVER_HOST', value: "${env.SERVER_HOST}"),
                                  string(name: 'SERVER_IP', value: "${env.SERVER_IP}"),
                                  string(name: 'DEPLOY_USER', value: "${env.DEPLOY_USER}"),
                                  string(name: 'DOCKER_IMAGE', value: "${env.DOCKER_IMAGE}"),
                                  string(name: 'SERVER_SSH_USER', value: "${SERVER_SSH_USER}"),
                                  string(name: 'WEB_CONTAINER_NAME', value: 'api'),
                                  string(name: 'PHP_CONTAINER_NAME', value: 'api-php'),
                                  password(name: 'SERVER_SSH_PASSWORD', value: "${SERVER_SSH_PASSWORD}"),
                                  text(name: 'EXTRA_ENVIRONMENT_VARIABLES', value: environmentVariablesProduction()),
                                  text(name: 'COMPOSE_FILE', value: readFile("docker-compose.server.yml")),
                                  booleanParam(name: 'LIQUIBASE_UPDATE', value: true),
                                  string(name: 'LIQUIBASE_USERNAME', value: "${LIQUIBASE_USERNAME}"),
                                  password(name: 'LIQUIBASE_PASSWORD', value: "${LIQUIBASE_PASSWORD}"),
                                  string(name: 'LIQUIBASE_CHANGELOG_PATH', value: '/var/www/html/data/database/basedata'),
                                  string(name: 'LIQUIBASE_URL', value: 'someJDBCUri),
                                  booleanParam(name: 'CLEANUP_MEMCACHED', value: true)
                              ]
                          }
                      }
                  }
              }
          }
      
          // post
      }
      

      Downgrading to 2.235 helped.

          [JENKINS-62305] Error "hudson.model.PasswordParameterValue.value expects class hudson.util.Secret" since 2.236

          Devin Nusbaum added a comment -

          danielbeck Do you recall why you had to switch the @DataBoundConstructor for PasswordParameterDefinition and PasswordParameterValue? Could we move @DataBoundConstructor back to the old constructors, and instead add a special case for stapler data binding only to this method to handle Secret?

          That way everything related to Structs data binding remains as before for compatibility, and things like doc generation would still work (doc generation against 2.236+ is broken because Secret is a parameter in the @DataBoundConstructor for PasswordParameterValue but Secret does not support data binding itself).

          While investigating I also noticed that the new "Change Password" button for password parameters doesn't seem to do anything in the Pipeline Snippet Generator UI, but any fix for that is probably distinct from the data binding issues.

          Devin Nusbaum added a comment - danielbeck Do you recall why you had to switch the @DataBoundConstructor for PasswordParameterDefinition and PasswordParameterValue ? Could we move @DataBoundConstructor back to the old constructors, and instead add a special case for stapler data binding only to this method to handle Secret ? That way everything related to Structs data binding remains as before for compatibility, and things like doc generation would still work (doc generation against 2.236+ is broken because Secret is a parameter in the @DataBoundConstructor for PasswordParameterValue but Secret does not support data binding itself). While investigating I also noticed that the new "Change Password" button for password parameters doesn't seem to do anything in the Pipeline Snippet Generator UI, but any fix for that is probably distinct from the data binding issues.

          Daniel Beck added a comment -

          dnusbaum

          Do you recall why you had to switch the @DataBoundConstructor for PasswordParameterDefinition and PasswordParameterValue? Could we move @DataBoundConstructor back to the old constructors, and instead add a special case for stapler data binding only to this method to handle Secret?

          See https://github.com/jenkinsci-cert/jenkins/pull/315#issuecomment-600876982 (Jenkins security team only) and the second/third commit in the PR.

          I expect that today it would emit irritating warnings during development due to https://github.com/jenkinsci/jenkins/blob/fd6c1509d17eff7d7a97d27f22d69f85df628c9e/core/src/main/java/hudson/Functions.java#L2087-L2091

          Note that one risk is if you don't round-trip as secret, every no-op save would change the job configuration since the encrypted value gets a new IV, something to watch out for. One of the drawbacks of the core change, and shown in the tests.

          Daniel Beck added a comment - dnusbaum Do you recall why you had to switch the @DataBoundConstructor for PasswordParameterDefinition and PasswordParameterValue ? Could we move @DataBoundConstructor back to the old constructors, and instead add a special case for stapler data binding only to this method to handle Secret ? See  https://github.com/jenkinsci-cert/jenkins/pull/315#issuecomment-600876982 (Jenkins security team only) and the second/third commit in the PR. I expect that today it would emit irritating warnings during development due to https://github.com/jenkinsci/jenkins/blob/fd6c1509d17eff7d7a97d27f22d69f85df628c9e/core/src/main/java/hudson/Functions.java#L2087-L2091 Note that one risk is if you don't round-trip as secret, every no-op save would change the job configuration since the encrypted value gets a new IV, something to watch out for. One of the drawbacks of the core change, and shown in the tests.

          We are also facing the same issue, appreciate any help fixing it. Thank you!

          Naresh Rayapati added a comment - We are also facing the same issue, appreciate any help fixing it. Thank you!

          lzhan lzhan added a comment -

          we are also facing the same issue, any update? so many password to handle....

          lzhan lzhan added a comment - we are also facing the same issue, any update? so many password to handle....

          Alex Hendriks added a comment -

          Same here. Went to LTS version because of this bug. LTS is on 2.235.1 now... next version will have this bug if not fixed. A lot op people will have huge problems!

          Alex Hendriks added a comment - Same here. Went to LTS version because of this bug. LTS is on 2.235.1 now... next version will have this bug if not fixed. A lot op people will have huge problems!

          lzhan lzhan added a comment -

          Hi danielbeck oleg_nenashev ,

          Any update? what we can do now is keeping on version 2.235....the neweset one is 2.244. 

          Thanks 

          lzhan lzhan added a comment - Hi danielbeck oleg_nenashev  , Any update? what we can do now is keeping on version 2.235....the neweset one is 2.244.  Thanks 

          M W added a comment -

          This seems fixed in the sense that I can pass in a string to a password parameter. But I had a Secret from my input parameters, so I had to convert my secret to a string first by using "${params.password}".

          M W added a comment - This seems fixed in the sense that I can pass in a string to a password parameter. But I had a Secret from my input parameters, so I had to convert my secret to a string first by using "${params.password}".

          Devin Nusbaum added a comment -

          I filed a draft PR to fix the immediate compatibility issues: https://github.com/jenkinsci/pipeline-build-step-plugin/pull/46. . Notably, from some discussion with jglick, it seems that password parameters were never really intended to be used with the build step, even though they happen to work. The recommended approach is to use credentials parameters instead, and only bind the credentials in the job that actually uses them. For example, in the Pipeline in the description of this issue, instead of binding the "database-maintenance" credential to "LIQUIBASE_PASSWORD" in the upstream job and then passing the password to as a parameter to the downstream job, you would pass "database-maintenance" as a credential parameter and then bind "LIQUIBASE_PASSWORD" in the downstream job when it is used. I am working on adding documentation to the plugin to make this recommendation explicit.

          Devin Nusbaum added a comment - I filed a draft PR to fix the immediate compatibility issues: https://github.com/jenkinsci/pipeline-build-step-plugin/pull/46.  . Notably, from some discussion with jglick , it seems that password parameters were never really intended to be used with the build step, even though they happen to work. The recommended approach is to use credentials parameters instead, and only bind the credentials in the job that actually uses them. For example, in the Pipeline in the description of this issue, instead of binding the "database-maintenance" credential to "LIQUIBASE_PASSWORD" in the upstream job and then passing the password to as a parameter to the downstream job, you would pass "database-maintenance" as a credential parameter and then bind "LIQUIBASE_PASSWORD" in the downstream job when it is used. I am working on adding documentation to the plugin to make this recommendation explicit.

          dnusbaum Thanks for making this clear. I've many broken projects now, but you're right it's better to only pass the credentials id to the jobs instead of the username/password directly. This also has the advantage of masking the username/password correctly in the jobs.

          Fabian Grutschus added a comment - dnusbaum Thanks for making this clear. I've many broken projects now, but you're right it's better to only pass the credentials id to the jobs instead of the username/password directly. This also has the advantage of masking the username/password correctly in the jobs.

          Devin Nusbaum added a comment -

          Pipeline: Build Step plugin version 2.13 was just released with a fix that should restore compatibility for password parameters when used with the build step.

          Devin Nusbaum added a comment - Pipeline: Build Step plugin version 2.13 was just released with a fix that should restore compatibility for password parameters when used with the build step.

            dnusbaum Devin Nusbaum
            fabiang Fabian Grutschus
            Votes:
            6 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: