-
Bug
-
Resolution: Fixed
-
Critical
-
Jenkins-Version=2.236
OS: Linux and Jenkins running in Docker container
-
-
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.
- is caused by
-
JENKINS-61808 Always encrypt f:password values, not just those backed by Secret
-
- Resolved
-
- relates to
-
-
- Resolved
-
- links to
[JENKINS-62305] Error "hudson.model.PasswordParameterValue.value expects class hudson.util.Secret" since 2.236
danielbeck would you be fine if I assign it to you?
P.S: personally I do not have strong opinion where to fix it. Jenkins core side workaround looks to be a convenient approach to prevent complicated upgrade steps, and to prevent other potential regressions.
Is this something we can handle on the pipeline side?
I guess this code could try to special-case PasswordParameterDefinition taking into account the current Jenkins version. I think it might make more sense though to update PasswordParameterDefinition.createValue(StaplerRequest, JSONObject) to hold the special-case logic instead.
Are there other contexts where parameters are instantiated (not just configured) via data binding (maybe JobDSL)? If so, I would expect them to be broken too.
CLI command and remote API come to mind as candidates. I'll take a look at those.
Sourabh Idoorkar
added a comment - Hi, I faced this same issue when I upgraded my Jenkins to latest version 2.237 recently. The only way I could temporarily get around this was by changing my pipeline from
password(name: 'PWD', value: PWD)
to
password(name: 'PWD', value: hudson.util.Secret.fromString(PWD))
But there are a few pipelines which are passing password params and so to avoid having to change this in all of them, I too had to revert back to older Jenkins
Sourabh Idoorkar
added a comment - Hi, I faced this same issue when I upgraded my Jenkins to latest version 2.237 recently. The only way I could temporarily get around this was by changing my pipeline from
password(name: 'PWD', value: PWD)
to
password(name: 'PWD', value: hudson.util.Secret.fromString(PWD))
But there are a few pipelines which are passing password params and so to avoid having to change this in all of them, I too had to revert back to older Jenkins 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.
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!
we are also facing the same issue, any update? so many password to handle....
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!
Hi danielbeck oleg_nenashev ,
Any update? what we can do now is keeping on version 2.235....the neweset one is 2.244.
Thanks
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}".
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.
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.
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. 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.
Caused by https://github.com/jenkinsci/jenkins/pull/4630
dnusbaum Is this something we can handle on the pipeline side? I'd rather not have to do another Object hack, the last one caused problems IIRC.