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

      Jenkins core currently depends on Groovy 2.4.21 (released on November 29, 2020), which is out of date. At the time of this writing, the oldest actively supported Groovy line is 2.5.x, and the latest version of Groovy 2.5.x is is 2.5.17 (released on May 28, 2022). This ticket proposes upgrading Groovy to the latest in the 2.5 series as a step to upgrading to 3.0.x (see JENKINS-51823).

      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-53372] Upgrade Groovy from 2.4.x to 2.5.x

          We are up to 2.5.11 - 

          Christian Bongiorno added a comment - We are up to 2.5.11 - 

          chb0jenkins - "we" might be subject to context interpretation.

          if "we" means "groovy" then it might be not that helpful to me.

          if "we" means "some commercial company" then it might show the subject is viable in at least a public or private demo installation.

          if "we" means "Jenkins" then you wanted to indicate that the update to that version already happened. - but then i dont understand why JENKINS-63047 is still an open issue in 2021 - whilst latest pessimistic sounding comments are from about 2020, if i saw right.

          Alexander Stohr added a comment - chb0jenkins - "we" might be subject to context interpretation. if "we" means "groovy" then it might be not that helpful to me. if "we" means "some commercial company" then it might show the subject is viable in at least a public or private demo installation. if "we" means "Jenkins" then you wanted to indicate that the update to that version already happened. - but then i dont understand why JENKINS-63047 is still an open issue in 2021 - whilst latest pessimistic sounding comments are from about 2020, if i saw right.

          Raphael added a comment -

          Jenkins still seems to run on 2.4.21, as per jenkinsci/jenkins:bom/pom.xml#44.

          According to endoflife.date/apache-groovy, that version does not receive security updates anymore.

          This is critical now.

          Raphael added a comment - Jenkins still seems to run on 2.4.21, as per jenkinsci/jenkins:bom/pom.xml#44 . According to endoflife.date/apache-groovy , that version does not receive security updates anymore. This is critical now.

          Paul added a comment -

          Groovy 2.4.x has been effectively EOL for about 4 years. We are currently voting on formally making it EOL right now. Jenkins is possibly the most widely used technology still on this old version, so we are dropping you a courtesy note here to let you know.

          Discussion: https://lists.apache.org/thread/ft6l7j331xxnj2sg1c2kz1mwz45mxyn3 
          Vote: https://lists.apache.org/thread/3lw8jvtfz98xjgz41xy9froxbdmxpo0k

          P.S. Does anyone have a feel for whether part of the sandboxing solution is generic enough to be widely applicable? Or is it quite specific to Jenkins? I can look myself I guess but thought someone might be in the know. Just wondering whether moving some kind of sandboxing solution into the Groovy project itself would make it easier for projects to upgrade Groovy versions.

          Paul added a comment - Groovy 2.4.x has been effectively EOL for about 4 years. We are currently voting on formally making it EOL right now. Jenkins is possibly the most widely used technology still on this old version, so we are dropping you a courtesy note here to let you know. Discussion: https://lists.apache.org/thread/ft6l7j331xxnj2sg1c2kz1mwz45mxyn3   Vote: https://lists.apache.org/thread/3lw8jvtfz98xjgz41xy9froxbdmxpo0k P.S. Does anyone have a feel for whether part of the sandboxing solution is generic enough to be widely applicable? Or is it quite specific to Jenkins? I can look myself I guess but thought someone might be in the know. Just wondering whether moving some kind of sandboxing solution into the Groovy project itself would make it easier for projects to upgrade Groovy versions.

          Devin Nusbaum added a comment - - edited

          P.S. Does anyone have a feel for whether part of the sandboxing solution is generic enough to be widely applicable? Or is it quite specific to Jenkins? I can look myself I guess but thought someone might be in the know. Just wondering whether moving some kind of sandboxing solution into the Groovy project itself would make it easier for projects to upgrade Groovy versions.

          At a high level, the sandboxing system is generic. The main pieces are in https://github.com/jenkinsci/groovy-sandbox (a generic Java library) and https://github.com/jenkinsci/script-security-plugin (a Jenkins plugin), but there are some parts specific to Jenkins Pipeline that live elsewhere. We received bug reports from non-Jenkins users in the groovy-sandbox repository, so there was at least some non-Jenkins interest in such a system (we eventually updated the README to explicitly discourage non-Jenkins usage because the sandbox can be trivially bypassed unless you are using related sandbox setup code in the script-security plugin).

          The goal of our sandbox is runtime interception of operations like constructor invocation, method calls, field accesses, etc., so that each operation can be checked against an allowlist and then either allowed or denied. This approach allows sandboxed scripts to use most Groovy language features internally and allows them to interact with known-safe Groovy/Java standard library APIs. It also means that the sandbox needs to understand how Groovy syntax maps to low level operations (e.g. what exactly will X as Y do at runtime?), which is complicated.

          The track record for our sandbox is not good (look at previous security warnings in the sidebar of https://plugins.jenkins.io/script-security/). If I was you I would not consider adding such a system to Groovy itself unless you had some specific idea of how to improve the design in a fundamental way or add defense-in-depth.

          Devin Nusbaum added a comment - - edited P.S. Does anyone have a feel for whether part of the sandboxing solution is generic enough to be widely applicable? Or is it quite specific to Jenkins? I can look myself I guess but thought someone might be in the know. Just wondering whether moving some kind of sandboxing solution into the Groovy project itself would make it easier for projects to upgrade Groovy versions. At a high level, the sandboxing system is generic. The main pieces are in https://github.com/jenkinsci/groovy-sandbox (a generic Java library) and https://github.com/jenkinsci/script-security-plugin (a Jenkins plugin), but there are some parts specific to Jenkins Pipeline that live elsewhere. We received bug reports from non-Jenkins users in the groovy-sandbox repository, so there was at least some non-Jenkins interest in such a system (we eventually updated the README to explicitly discourage non-Jenkins usage because the sandbox can be trivially bypassed unless you are using related sandbox setup code in the script-security plugin). The goal of our sandbox is runtime interception of operations like constructor invocation, method calls, field accesses, etc., so that each operation can be checked against an allowlist and then either allowed or denied. This approach allows sandboxed scripts to use most Groovy language features internally and allows them to interact with known-safe Groovy/Java standard library APIs. It also means that the sandbox needs to understand how Groovy syntax maps to low level operations (e.g. what exactly will X as Y do at runtime?), which is complicated. The track record for our sandbox is not good (look at previous security warnings in the sidebar of https://plugins.jenkins.io/script-security/ ). If I was you I would not consider adding such a system to Groovy itself unless you had some specific idea of how to improve the design in a fundamental way or add defense-in-depth.

            Unassigned Unassigned
            allanlewis_youview Allan Lewis
            Votes:
            20 Vote for this issue
            Watchers:
            30 Start watching this issue

              Created:
              Updated: