sec-170: What need plugins to do to declare vars they provide?

[Björn Pedersen]

Hi,

Since sec-170 all unknown variables  will get dropped. What needs to be done in a plugin to correctly declare the vars they provide?

Björn

[Robert Sandell]

One alternative is to implement and EnvironmentContributor, one example here https://github.com/jenkinsci/ghprb-plugin/pull/336

If I'm reading the code correctly on ParametersAction the above alternative would still print nasty warnings in the Jenkins log though, so I'm going to try to hack my way to adding to the safeParameters field instead.

/B

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6ef47e98-d70c-4a9d-be82-2b91ad0ce009%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Daniel Beck]

> On 12.05.2016, at 11:03, Robert Sandell <rsan...@cloudbees.com> wrote:
>
> so I'm going to try to hack my way to adding to the safeParameters field instead

Are you trying to force me into removing it?

[Daniel Beck]

> On 12.05.2016, at 10:48, 'Björn Pedersen' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> Since sec-170 all unknown variables will get dropped. What needs to be done in a plugin to correctly declare the vars they provide?

My blog post mentions a few options towards the end:
https://jenkins.io/blog/2016/05/11/security-update/

Personally I'd prefer plugin developers use the second option -- often, what's passed as parameters aren't actually parameters per se, it probably just was the most straightforward way to implement it.

[Robert Sandell]

Really?

System.setProperty("hudson.model.ParametersAction.safeParameters", existing + "MY,OWN")

seems like a valid option without breaking anything to me?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D73CB19D-FB7B-48C5-A7C6-EDE3E636B03F%40beckweb.net.

For more options, visit https://groups.google.com/d/optout.

[Daniel Beck]

> On 12.05.2016, at 15:08, Robert Sandell <rsan...@cloudbees.com> wrote:
>
> System.setProperty("hudson.model.ParametersAction.safeParameters", existing + "MY,OWN")
> seems like a valid option without breaking anything to me?

May just be me, but this looks like a clear abuse of the escape hatch user option.

Note that we don't guarantee that system properties stick around forever, so a solution using supported APIs would be a better idea.

If the extra parameters warning message is what's motivating this approach, maybe we should look into changing that instead?

[Robert Sandell]

Yes I think we should, I can only blame myself for not being around to catch it before it was merged :)

But at the same time I need to get a fix out for my users.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2B805E11-6310-432E-B9F0-DC36D0DED3CF%40beckweb.net.

For more options, visit https://groups.google.com/d/optout.

[Daniel Beck]

> On 12.05.2016, at 16:47, Robert Sandell <rsan...@cloudbees.com> wrote:
>
> But at the same time I need to get a fix out for my users.

I fear that early implementations to handle this new restriction will be heavily copy/pasted. So even if you intend to switch to a different approach as soon as you consider it viable, other plugins may not, perpetuating this hackish approach.

[Kanstantsin Shautsou]

EnvironmentContributor is the worst thing for trigger plugins imho. Trigger plugins injecting known and safe named variables, they should never be filtered out from job variables. 

Hiding vars for already setuped envs sounds like a disaster.

[Jesse Glick]

Just set variables according to a `Cause` or similar.

[Kanstantsin Shautsou]

> On May 13, 2016, at 01:33, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> Just set variables according to a `Cause` or similar.
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/YNLEDaGUsgg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3jBSXM%2BEN7QQnKUjbPxFcjFm%2BMQ%3DQiiabok9KJzh9a9A%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

Where? EnvironmentContributor? It participates in spaghetti routines of variable resolvers that full of infinite bugs for different types of jobs. It wrong architecture for providing things that must be in first place (triggered values and cause) instead of doing additional resolution calls and duplicating everything else.
Where is trusted field in StringParameter or any other objects then?