• Type: Bug
• Resolution: Unresolved
• Priority: Major
• Component/s: parameterized-trigger-plugin
• Labels:

  None
• Environment:

  win server host
  Jenkins version 2.3
  Parameterized Trigger plugin version 2.30

1. 

   config.jpg

   91 kB

   2016-05-17 07:43

[JENKINS-34871] After upgrading to Jenkins 2.3 we are unable to trigger parametrized build (SECURITY-170 / CVE-2016-3721)

Vassilena Treneva created issue - 2016-05-17 07:42

Vassilena Treneva made changes - 2016-05-17 07:43

Attachment

New: config.jpg [ 32733 ]

Vassilena Treneva made changes - 2016-05-17 07:43

Description

Original: 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 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?

New: 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?

Vassilena Treneva made changes - 2016-05-17 07:44

Environment

New: win host Jenkins version 2.3

Vassilena Treneva made changes - 2016-05-17 07:45

Description

Original: 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?

New: 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?

Vassilena Treneva made changes - 2016-05-17 07:45

Summary

Original: After upgrading to Jenkins 2.3 we are unable to trigger parametrized build (due to SECURITY-170 / CVE-2016-3721?)

New: After upgrading to Jenkins 2.3 we are unable to trigger parametrized build using prop file (due to SECURITY-170 / CVE-2016-3721?)

Vassilena Treneva made changes - 2016-05-17 07:47

Environment

Original: win host Jenkins version 2.3

New: win server host Jenkins version 2.3 Parameterized Trigger plugin version 2.30

Vassilena Treneva made changes - 2016-05-17 07:47

Priority

Original: Blocker [ 1 ]

New: Major [ 3 ]

Vassilena Treneva made changes - 2016-05-17 07:47

Summary

Original: After upgrading to Jenkins 2.3 we are unable to trigger parametrized build using prop file (due to SECURITY-170 / CVE-2016-3721?)

New: After upgrading to Jenkins 2.3 we are unable to trigger parametrized build using prop file (maybe due to SECURITY-170 / CVE-2016-3721?)

Collapse comment: Lars added a comment - 2016-05-17 08:15

Lars added a comment - 2016-05-17 08:15

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.

Expand comment: Lars added a comment - 2016-05-17 08:15

Lars added a comment - 2016-05-17 08:15 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.

Load more newer events