Hello Robert, thanks for the feedback.
I try to be more concrete. We have a collection of maintenance system groovy scripts, which we have stored in a git repository. One of the scripts for example purges orphan or old workspaces. We then have a time triggered Jenkins Job that fetches the script from git and calls it via "Execute System Groovy Script" Build step and for example "jenkins/PurgeWorkspace.groovy" as script file from just fetched workspace. These scripts are now not trusted by default any more they require the security settings to be opened up, for example to get around "Scripts not permitted to use staticMethod hudson.model.Hudson getInstance". Also, if the script is more complex and the classpath needs to be extended (to point somewhere in the workspace) this does not seem to be possible at all. This was done via the "Classpath" option in the System Groovy build step before. This leads to my proposal to be able to mark one or several of the Pipeline Shared Groovy Libraries as "Places on trusted system classpath" to be able to put our scripts in such a library and being able to call them again in a Jenkins Job. I did not use the Scriptler Plugin yet. Seeing that it was not updated for more than a year now makes me a bit reluctant in testing it out. For some reason I can not find it in the update center? Might be, there is a different solution? Kind Regards, Andreas. Am Montag, 8. Mai 2017 12:43:39 UTC+2 schrieb Robert Sandell: > > I'm not really sure what you are asking here, how did you call these > scripts before? > > A Pipeline Shared Groovy Librariy that is trusted is able to call any > Jenkins api since it is not running in the sandbox, although still running > in CPS, but should still be able to call for example > RemotingDiagnostics.executeGroovy even though it is a biig security risk to > do so. > > The scriptler plugin has a library feature iirc that can also be run as a > build step. > > /B > > On Sun, May 7, 2017 at 3:09 PM, 'Bruno P. Kinoshita' via Jenkins > Developers <[email protected] <javascript:>> wrote: > >> +1 Andreas >> >> >> Wanting the same right now. Started a small sandbox [1] some time ago to >> try understand everything I would need for active-choices, but got >> distracted by security and performance issues. >> >> * Execute a Groovy script >> * Allow user to add extra jars >> * Graple dependency management support >> * Option to enable script-security integration (on by default) >> >> The Groovy execution layer in active-choices came from >> dynamicparameter-plugin, then was a bit tweaked. Later we added >> script-security. Now need to look into extra jars (right now integrating >> ImageJ). >> >> Cheers >> Bruno >> [1] https://github.com/kinow/groovy-script-lib >> >> ________________________________ >> From: Andreas Mandel <[email protected] <javascript:>> >> To: Jenkins Developers <[email protected] <javascript:>> >> Sent: Sunday, 7 May 2017 10:14 PM >> Subject: Pipeline Shared Groovy Libraries and system groovy script >> classpath >> >> >> >> Hi List, >> >> since the last security updates, a common practice to work with system >> groovy scripting does not work any more. It might be easily resolvable with >> a small(?) change in the Pipeline Shared Groovy Libraries plugin. >> >> We have a lot of system groovy scripts in Jenkins jobs that take care for >> cleanup, monitoring, etc. These jobs check out certain scripts from SCM and >> then call them as a system groovy script. With the recent changes, you >> cannot simply add and call something "dynamic" in the workspace as system >> groovy script anymore. I do not want to go a step back and put the whole >> code inside the Jenkins job definition. >> >> On the other hand with the Pipeline Shared Groovy Libraries plugin we now >> have a quite powerful library management plugin for groovy libraries. >> Unfortunately as of now this only works for pipeline jobs and not for the >> use in system groovy scripts. >> >> Would it be possible to add a functionality to mark a library in the >> Pipeline Shared Groovy Libraries plugin as "system groovy library" and so >> make it available on the class path of any system groovy script? >> >> Could this work out? How are other resolving this topic? >> >> >> Thanks, >> Kind Regards, >> Andreas. >> >> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/c3537dfe-c206-428d-9e3a-7a298d98a785%40googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/800881429.5606274.1494162579878%40mail.yahoo.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Robert Sandell > *Software Engineer* > *CloudBees Inc.* > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bdcbf863-31da-4d7c-9992-6668f3b89ab7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
