Hi Sandesh, Whitelisting of "groovy.lang.Closure" is a bad idea IMHO, because it will whitelist this class everywhere within Jenkins Remoting and XStream serialization.
My recommendation would be to rather rework the closure to a Callable/Runnable class and whitelist this particular implementation if needed. BTW, it would be really interesting to understand your use-case. Why would you need to send Groovy closures over Remoting? Best regards, Oleg On Friday, April 27, 2018 at 9:47:31 AM UTC+2, Sandesh Wani wrote: > > Hi, > > [ERROR] Failed to deserialize response to > UserRequest:com.abc.jenkins.plugins.xyz.pqr.vuw@494947d9: > java.lang.SecurityException: Rejected: groovy.lang.Closure; see > https://jenkins.io/redirect/class-filter/ > > I got the above error while building mixed groovy-java project in jenkins. > As mentioned in https://jenkins.io/blog/2018/01/13/jep-200/ --> "If the > class(es) are defined in a third-party library bundled in your plugin, > create a resource file *META-INF/hudson.remoting.ClassFilter* listing > them. (example > <https://github.com/jenkinsci/workflow-support-plugin/pull/50/files>)" > > I added the *hudson.remoting.ClassFilter* file with the following > content: *groovy.lang.Closure* > > Though my build was successful after adding this fix but I am not sure > about how safe it is to do this. Security concerns? > > So my question is, will the above fix whitelist all the > *groovy.lang.Closure* or just the *groovy.lang.Closure* in my project. In > short what is the scope of *hudson.remoting.ClassFilter*? > -- 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/32cd9489-a6e0-4ebb-94a2-b2e52e91511c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
