search

jenkinsci / groovy-sandbox

(Deprecated) Compile-time transformer to run Groovy code in a restrictive sandbox
MIT License
123 stars 60 forks source link

Consider Bump to Groovy 2.x #19

Closed spmallette closed 5 years ago

spmallette commented 10 years ago

Seems that groovy-sandbox works well with Groovy 2.x when I exclude groovy 1.8 dependency in my pom, but it would be nice to see a dependency bump.

Kinda funny - we've been resisting the bump to Groovy 2.x in TinkerPop for a long time. Now, here I am requesting a groovy version bump consideration in someone else's lib. oh well.... :smile:

msymons commented 9 years ago

There's now an additional reason to bump the dependency...

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3253

The MethodClosure class in runtime/MethodClosure.java in Apache Groovy 1.7.0 through 2.4.3 allows remote attackers to execute arbitrary code or cause a denial of service via a crafted serialized object.

Fixed in Groovy v2.4.4:

http://groovy-lang.org/security.html

Whilst this bulletin does provide guidance on mitigation. one would still be stuck with alerts from security tools.

jglick commented 7 years ago

We could go up to Groovy 2.x but this would require making the script-security plugin require Jenkins 2.x as well. So far we have not wanted to cut off 1.x users but maybe it is time now. workflow-cps (for Pipeline) as of its latest security advisory does require 2.x, so the only reason to hold off would be to deliver non-security-related script-security updates to non-Pipeline plugins with a 1.x baseline. But it has been over a year since 2.7.1 LTS was released, and there have been so many security advisories since then that anyone using 1.x would be better advised to just disable security and stop pretending, in which case they are unlikely to need such fixes anyway.

dwnusbaum commented 5 years ago

This library is using Groovy 2.x as of https://github.com/jenkinsci/groovy-sandbox/pull/35.