Script Security Plugin Questions

[Slide]

I am finally getting the time to add the Script Security Plugin to email-ext. The problem I am looking at is that scripts are used as variables, by this I mean an administrator can set a default pre-send script in the global configuration and then in a project specify $DEFAULT_PRESEND_SCRIPT, which is then replaced by the global configuration value. Will this cause issues with the Script Security Plugin? 

Thanks,

slide

[Jesse Glick]

On Thu, Feb 26, 2015 at 9:24 AM, Slide <slide...@gmail.com> wrote:
> an administrator can set a default pre-send script
> in the global configuration and then in a project specify
> $DEFAULT_PRESEND_SCRIPT, which is then replaced by the global configuration
> value. Will this cause issues with the Script Security Plugin?

I suppose you mean that the project configuration might take any of
the following forms:

· $DEFAULT_PRESEND_SCRIPT
· if (isFullMoon()) {$DEFAULT_PRESEND_SCRIPT}
· Jenkins.instance.securityRealm = null

Right?

I think this can work fine with the whole-script approval mode. When
configuring the project (thus in some @DataBoundConstructor called
from the EmailExtPublisher, as well as its readResolve), call the
`configuring` method with whatever text has been passed in to the
script field, if all variables can be successfully expanded at the
time (else skip it). Call `using` before running the script, obviously
with all variables expanded. Also when the administrator (someone with
Jenkins.RUN_SCRIPTS) is saving global configuration, call
`configuring` with the default scripts. Thus, the first project
configuration would be guaranteed to pass, because the script is
already trusted; the second and third would wait for admin approval,
as expected.

If you are supporting Groovy sandbox mode, it is irrelevant who
configures the script or how. It either runs or it does not, based
solely on the operations it attempts.