-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
win server host
Jenkins version 2.3
Parameterized Trigger plugin version 2.30
After upgrading to Jenkins 2.3 we are not able to pass a custom parameter specified in a property file. It looks like there is a security feature in this versions (https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11) that disables simply passing build parameters.
This makes no sense to me since in my configuration (attached picture - config.jpg) I explicitly specify that I need to trigger the build with predefined properties.
Maybe I am missing something?
I tried to get the suggested solution working on slave level (passed java -Dhudson.model.ParametersAction.safeParameters=myParam) to slave start-up but this does not work. It looks like this needs to be passed when we start the master but this is no workaround. We simply have a lot of parameters and we cannot pass them to master at start-up.
Again - maybe I am missing something in this workaround?
- is duplicated by
-
JENKINS-34954 Upgrade from LTS 1.651.1 to 1.651.2 broke functionality of parameterized trigger plugin
-
- Open
-
-
JENKINS-34873 Parameters are not passed to downstream jobs
-
- Resolved
-
-
JENKINS-35113 Upgrade to 1.651.2 or 2.6.x breaks 'Parameters from properties file' in 'Parameterized Trigger' plugin
-
- Resolved
-
-
JENKINS-34911 Post-build action "Trigger parameterized build on other projects" does not pass predefined parameters
-
- Resolved
-
-
JENKINS-40038 Parameterized Trigger Plug-in broken with Jenkins core 2.33
-
- Resolved
-
-
JENKINS-38558 parameterized trigger plugin is not working on Jenkins 2.23
-
- Closed
-
- links to
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.