Scope of hudson.remoting.ClassFilter file added to whitelist the class? (Jenkins JEP-200 issue)

[Sandesh Wani]

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)"

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?

[Oleg Nenashev]

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

[Jesse Glick]

On Fri, Apr 27, 2018 at 5:22 AM, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> My recommendation would be to rather rework the closure to a
> Callable/Runnable class

Better to write the affected code in Java. Save the Groovy for something else.