|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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.