So if you use the newest plugin, but disable the sandbox.  We then use the Authorize Project plugin to ensure jobs are run by default as non-admin.  This will cause the plugin to still ask for approval when running the job on periodic/automatic triggers, but it will approve the entire script rather than individual signatures.

The script is being read from an hg repo in the workspace so the sandbox checkbox is not available in our case. (and I'd rather avoid using the inline script approach with a 1000 line script~)

bonuslord We have the same issue but use job dsl to read the file from the repo at the current version and prep the inline script job.

Ooo, interesting solution; hadn't actually heard of the Job DSL plugin but it looks pretty useful...

bonuslord We have almost completely removed manual configuration of jobs from our workflow, except for the job running the DSL

We have the same issue here - 2.0 broke practically all our scripts. All devs on the team are admins on the team Jenkins boxes, so the sandbox really adds no value to us.

Pasting the file-based system scripts into the Jenkins jobs is undesirable, as we'd lose the ability to do code review etc. on them like we do with other changes.

Whitelisting is not an option, as some of the scripts use properties on nodes returned by XmlParser(), and those end up as "unclassified field", and thus are not possible to whitelist.

Tried downgrading, but that resulted in the scripts that /were/ part of the jobs (as opposed to being files - we do that for jobs that are not tied to any particular repo) being wiped.

Latest upgrade from LTS 2.32.2 to LTS 2.60.3 basically killed all our system groovy script steps as they all come from a file and are not pasted directly in the jobs.

The scripts now take approximately 100-200 times (YES, REALLY!!!) longer than before which of course caused some jobs running into timeouts.

We really need the option to run the "Execute System Groovy Script" from a FILE without Sandbox.

Pasting the whole scripts into the jobs is completely ridiculous...

I found a workaround for everyone interested.... Works like a charm and is very very fast.

Our report script takes 28 seconds with this code snippet to run instead of 30 MINUTES when running directly referenced with filename running in the sandbox.
Just paste this code in a "Execute System Groovy Script" build step and make sure the Sandbox Checkbox is NOT checked.
And of course make sure the script file is in your workspace

import hudson.FilePath;

def filename = "/ReportScripts/AutomationMatrix.groovy"

if(build.workspace.isRemote()) {
  fp = new FilePath(build.workspace.channel, build.workspace.toString() + filename)
  evaluate(fp.readToString())
} else {
  fp = new FilePath(new File(build.workspace.toString() + filename))
  evaluate(fp.readToString())
}

Enjoy!

It has never been easier to work around any security measure i encountered before....
This script security thing is completely worthless and should be removed from jenkins until its redesigned...

best regards,

Alex

A bit shorter version of Alex's solution:

def name = "ReportScripts/AutomationMatrix.groovy";
evaluate(build.project.workspace.child(name).readToString())