The way to provide presets:

• Built into script-security
• Built into script-security and administrators can switch enabled/disabled.
  • For the case administrators want complete restriction.
• script-security provides "import signatures from a file" and signature files are distributed on Wiki page.
  • For the case administrators don't want presets updated with plugin updates.

The plugin already ships with a small static whitelist. It needs to be greatly expanded to cover clearly safe Java platform APIs (such as string manipulation), as well as neutral things in the Jenkins API. (Anything in the Jenkins API which calls checkPermission is generally OK to whitelist given a permissions check—this is a separate whitelist mode.)

I think it is best to just have this default whitelist be bundled in the plugin, so we can use routine plugin updates to distribute it. And I see no reason to make it configurable. Either there is a known (or reasonably suspected) risk from some method in the standard whitelist, in which case it should be removed and a plugin update distributed as a regular security fix; or there is not, and it should be included. Administrators should not be expected to do the deep thinking.

Ran into a few when trying to use Regex and the Groovy extension methods:

method java.util.Map containsKey java.lang.Object
method java.util.regex.Matcher matches
staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods collectEntries java.util.Collection groovy.lang.Closure
staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods findAll java.util.List groovy.lang.Closure

It seems like there is a lot of language features and manipulation that should be added to the default whitelist. It is annoying for an administrator to have to address every single one of these. What else is being considered for the standard whitelist in terms of built-in Java/Groovy methods?

This ticket is a bit open-ended. What's the conditions that needed to be satisfied to mark this ticket closed?

The plugin already ships with a small static whitelist.

On a clean 2.7.4 Jenkins instance the "In-process Script Approval" is empty.

I wanted this left open to track the task of proactively whitelisting a lot of things as a streamlined batch operation, rather than reactively whitelisting things people have bothered to complain about as relatively expensive one-off PRs.

Admittedly it is a bit open-ended, but there are some plausible success criteria. For example, everything in java.lang and java.util (as of Java 7, say) that looks safe should be added.

I also have a problem related to this, It seems that I need to add "hudson.plugins.git.GitSCM getBranches" because my jobs fail with this error:

org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method hudson.plugins.git.GitSCM getBranches

The big problem is that is currently impossible to approve these because this is never reaching the scriptApproval page, which also does not allow us to introduce free-form text.

How to solve this?

Unrelated to this issue ssbarnea.

Proposed addition: The entire Java 8 date-time API. I was trying to extract some basic job information and ran into a blocked LocalDate#getYear().

I was looking to add a bunch of Java 8 java.time but ran into test failures because the plugin seems to only support Java 7.

> java.lang.AssertionError: method java.time.Instant adjustInto java.time.temporal.Temporal does not exist (or is an override)

Any thoughts on how to support these?

mkobit if you are referring to the https://jenkins.ci.cloudbees.com/job/plugins/job/script-security-plugin/ CI job, this was misconfigured, now fixed to run on JDK 8.

Awesome, thanks jglick! Going to take another pass at it and open a PR.

Closing this as won't fix - if you've got additional signatures you want added, open individual tickets for them.

abayer FWIW the idea was to proactively search for safe-looking methods in commonly used packages, rather than wait for failures to trickle in.