• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • None

      Jenkins core currently depends on Groovy 2.4.21 (released on November 29, 2020), which is out of date. Once we upgrade to 2.5.x, the next major version of Groovy is 3.0.x. At the time of this writing, the latest version of Groovy 3.0.x is 3.0.11 (released on May 28, 2022). Groovy 3.0 is required to run on Java 11+ without reflective access warnings logged on startup.

      As described in jenkinsci/jenkins#5112 (comment) and jenkinsci/jenkins#5116 (comment), the main concern when upgrading Groovy is ensuring that sandboxed script execution remains secure.

          [JENKINS-51823] Upgrade Groovy from 2.5.x to 3.0.x

          Alexander Stohr added a comment - is it possible? yes/no i have varying indications, e.g. this one tells about 2.5.x was used: https://issues.jenkins.io/browse/JENKINS-53372?focusedCommentId=370924&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-370924

          Ian Williams added a comment -

          oleg_nenashev, OP says groovy 3.x required to tun on Java 10.

          The the discussion is to move core baseline to Java 11, does that not also require a move to Groovy 3.x?

          Ian Williams added a comment - oleg_nenashev , OP says groovy 3.x required to tun on Java 10 . The the discussion is to move core baseline to Java 11 , does that not also require a move to Groovy 3.x?

          Oleg Nenashev added a comment -

          ianw yes, it may require a move to Groovy 3.x. Note that we do not have a consensus about moving to Java 11+ at the moment. We will be updating the Docker images to use Java 11 by default, and then we will see what is the feedback

          Oleg Nenashev added a comment - ianw  yes, it may require a move to Groovy 3.x. Note that we do not have a consensus about moving to Java 11+ at the moment. We will be updating the Docker images to use Java 11 by default, and then we will see what is the feedback

          Ian Williams added a comment -

          As long as the Jenkins team keep this in mind when making any decision for 8 -> 11. Would the to see that go ahead and then all sorts of things go South, worse than tables to divs, based on the level of effort and potential blast radius if Groovy u/g was overlooked, especially since as it stand now, 8's availability will exceed 11's .

          Ian Williams added a comment - As long as the Jenkins team keep this in mind when making any decision for 8 -> 11. Would the to see that go ahead and then all sorts of things go South, worse than tables to divs, based on the level of effort and potential blast radius if Groovy u/g was overlooked, especially since as it stand now, 8's availability will exceed 11's .

          Tim Jacomb added a comment -

          I did a spike on this awhile back

          Updating the version itself does work work in Jenkins, basic smoke testing produced no issues.

          But there's a lot more work needed to be done to validate it,

          See some comments on the work required:
          https://github.com/jenkinsci/jenkins/pull/5112#issuecomment-744429487
          https://github.com/jenkinsci/jenkins/pull/3605#issuecomment-465557917

          Tim Jacomb added a comment - I did a spike on this awhile back Updating the version itself does work work in Jenkins, basic smoke testing produced no issues. But there's a lot more work needed to be done to validate it, See some comments on the work required: https://github.com/jenkinsci/jenkins/pull/5112#issuecomment-744429487 https://github.com/jenkinsci/jenkins/pull/3605#issuecomment-465557917

          Jesse Glick added a comment -

          One approach might be to redesign the sandbox compiler transformer (and perhaps also the CPS transformer, since they are somewhat interlinked) so that it defaults to rejecting unrecognized language constructs. I am not sure offhand if this is technically feasible, but it would certainly make updates much safer than they are today. This is by no means a complete solution, since Groovy updates also change behavior beyond the syntactic level in ways that can open up sandbox escapes in complex ways.

          Jesse Glick added a comment - One approach might be to redesign the sandbox compiler transformer (and perhaps also the CPS transformer, since they are somewhat interlinked) so that it defaults to rejecting unrecognized language constructs. I am not sure offhand if this is technically feasible, but it would certainly make updates much safer than they are today. This is by no means a complete solution, since Groovy updates also change behavior beyond the syntactic level in ways that can open up sandbox escapes in complex ways.

            Unassigned Unassigned
            oleg_nenashev Oleg Nenashev
            Votes:
            31 Vote for this issue
            Watchers:
            42 Start watching this issue

              Created:
              Updated: