Same here, this change broke several of my jobs that need to pass undeclared parameters.
I was able to fix this by setting hudson.model.ParametersAction.keepUndefinedParameters to true as said in the security advisory.
But the security advisory also said that this is a short-term workaround which made me worry. If the user does not consider this behaviour unsafe, he should be able to enable it.

Hi Lars,

Where did you set this to resolve the problem everywhere? Slave level?

And a side comment - we have quite a lot of parameters and I cannot imagine passing explicitly all of them. This completely throws away the ability to start builds with prop files...

I set this property on master - we only have one master. So my problem with this change is not as difficult as yours.
And I only set hudson.model.ParametersAction.keepUndefinedParameters=true to completely disable this new behaviour and did not pass all safe parameters, because I don't think that this is maintainable.

Okay. Thanks.

Another question then - typically we start Jenkins using command line args in Jenkins home like: <jenkins start> or <jenkins stop> and these commands on their turn invoke jenkins.war file.
How exactly did you set hudson.model.ParametersAction.keepUndefinedParameters=true? Started Jenkins by invoking the .war file directly? How do you know all the arguments that are typically passed to it?

Same issue, We have slaves, does this need to applied to them as well?

I've altered /etc/sysconfig/jenkins (as we are RHEL Based) added the parameter: -Dhudson.model.ParametersAction.safeParameters=true on the master.

However, I'm still seeing within Jenkins error log:

WARNING: Skipped parameter `xxyyzz` as it is undefined on `xxyyzz/Container.Hosts=slave.02`. Set `-Dhudson.model.ParametersAction.keepUndefinedParameters`=true to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach

vassilena
Dependent on OS versions: additional args can be defined in the file:

/etc/default/jenkins
/etc/sysconfig/jenkins

Im not sure if it should be placed in: JENKINS_ARGS or JENKINS_JAVA_OPTIONS

–
I restart jenkins via service jenkins restart, I can confirm via htop or ps that the parameter is being set but still no luck
–

Edit:
All working, For some strange reason I have to have -Dhudson.model.ParametersAction.keepUndefinedParameters=true

defined both in:

*JENKINS_ARGS *and *JENKINS_JAVA_OPTIONS *within the /etc/sysconfig/jenkins file.

I have only implemented this on the Master but the slaves seem happy to cooperate with it.

My master Jenkins (unfortunately) is hosted on windows platform and I cannot make it work.
I tried adding this line:
<arguments>-Dhudson.model.ParametersAction.safeParameters=true -jar "%BASE%\jenkins.war"</arguments>

in %JENKINS_HOME%/jenkins.xml, so after I edited the <service> tag it looks like this:
<executable>%BASE%\jre\bin\java</executable>
<arguments>-Dhudson.model.ParametersAction.safeParameters=true -jar "%BASE%\jenkins.war"</arguments>
<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8080</arguments>

I also tried adding JENKINS_JAVA_OPTIONS & JENKINS_ARGS as windows environment variables.

No success with either approaches.

Any ideas?

EDIT: I was putting the wrong parameter (hudson.model.ParametersAction.safeParameters instead hudson.model.ParametersAction.undefinedParameters)
Switched to the right one and it works as before.

This is one plugin whose breakage is deliberate, and in fact the whole point of the security update. It allowed users of one job (Job A) to provide arbitrary arguments to a different job (Job B), even if the creator of Job B doesn't define those parameters. This enables a number of attacks, the most generic being the one described in broad strokes using PATH in the advisory.

The correct way to handle this is to extend your triggered/downstream jobs (every "Job B") to accept additional parameters.

Besides that, adding the parameters to a project causes them to be editable by the user in case of a manual build. In some cases this is not intended. Some parameters are only needed when triggered by another project.

But this means I need to change a lot of projects if I want to upgrade to a Jenkins version newer than 2.2.
Isn't there any other solution than changing all the projects B (called by projects A)?

Well, you can always disable this protection mechanism. It's specifically for existing instances that for one reason or another need to rely the existing behavior.

adding the parameters to a project causes them to be editable by the user in case of a manual build. In some cases this is not intended. Some parameters are only needed when triggered by another project.

It's not possible for Jenkins to distinguish between "intended" additional parameters and "unintended" additional parameters, and since they're used to override environment variables, the safe approach is to not allow them. But I wouldn't be surprised if there's a plugin out there that provides an 'invisible' parameter type that can only be customized by launching programmatically. Possibly this one, but haven't tested it.

Well, you can always disable this protection mechanism. It's specifically for existing instances that for one reason or another need to rely the existing behavior.

Always? https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11 said this is "intended as a short-term workaround only".

Thank you for proposing the Hidden Parameter Plugin. I didn't know it. I will give it a try.

It is also possible to turn the bucket upside-down.. I have played with a patch for the envinject plugin that regex-based retrieve parameters from upstream build. This way B is reading A and not A pushing to B..
This way parameters just need to be stored in A's environment. You do not need to use parameterized trigger - but any upstream/downstream trigger

How does this sound?

Same when trying to use "Use properties from file"

When we will have a fix for it?
When i downgraded to 2.19.4 i still have this problem

"The correct way to handle this is to extend your triggered/downstream jobs (every "Job B") to accept additional parameters."
By enabling in project B the option "This project is parameterized" and adding parameters with the same name as the one passed by the project A.

Confirming this worked for me.

After adding "-Dhudson.model.ParametersAction.keepUndefinedParameters=true" to /etc/sysconfig/jenkins file in jenkins-2.46.3-1.1.noarch version. It works. Since it has reported as a security fix. Can we have a permanent fix for this bug?