Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-28687

spring version (2.5.x) is ancient and not compatable with many new libraries

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core

      The spring version 2.5 used in core is very old and this makes it problematic when trying to integrate jenkins with another component, or integrating components within jenkins as most things have moved way passed 2.5 to 4.x.

      Note - this may also require an upgrade of groovy.

          [JENKINS-28687] spring version (2.5.x) is ancient and not compatable with many new libraries

          Jake Remitz added a comment - - edited

          Also note that CVE-2011-2730 is also present with this version of Spring for spring-web-2.5.6.SEC03.jar, spring-core-2.5.6.SEC03.jar, context-support-2.5.6.SEC03.jar, and spring-context-2.5.6.SEC03.jar.

          CVE-2011-0766 impacts crypto-util-1.1.jar which I'm not aware whether this is tied to Spring directly or it's own issue.

          There are also a couple of lower priority security findings that span across some of the other Spring packages of this version: CVE-2010-1622 and CVE-2013-6429.

          Jake Remitz added a comment - - edited Also note that CVE-2011-2730 is also present with this version of Spring for spring-web-2.5.6.SEC03.jar, spring-core-2.5.6.SEC03.jar, context-support-2.5.6.SEC03.jar, and spring-context-2.5.6.SEC03.jar. CVE-2011-0766 impacts crypto-util-1.1.jar which I'm not aware whether this is tied to Spring directly or it's own issue. There are also a couple of lower priority security findings that span across some of the other Spring packages of this version: CVE-2010-1622 and CVE-2013-6429 .

          Daniel Beck added a comment -

          CVE-2011-0766 impacts crypto-util-1.1.jar which I'm not aware whether this is tied to Spring directly or it's own issue.

          crypto-util is a library by the Jenkins project. The CVE points to Erlang Open Telecom Platform and is pretty obviously unrelated.


          There are also a couple of lower priority security findings that span across some of the other Spring packages of this version: CVE-2010-1622 and CVE-2013-6429.

          If you look up the CVE descriptions or advisory, you will find:

          • CVE-2010-1622: "SpringSource Spring Framework 2.5.x before 2.5.6.SEC02…" (and you can stop reading right there)
          • CVE-2013-6429: No mention of 2.x on https://tanzu.vmware.com/security/cve-2013-6429 and according to the Spring Javadoc, the class was introduced in Spring 3.0.

          jremitz Could you clarify whether you did any research here and I missed something, or whether you just dumped a security scan result here?

          Daniel Beck added a comment - CVE-2011-0766 impacts crypto-util-1.1.jar which I'm not aware whether this is tied to Spring directly or it's own issue. crypto-util is a library by the Jenkins project. The CVE points to Erlang Open Telecom Platform and is pretty obviously unrelated. There are also a couple of lower priority security findings that span across some of the other Spring packages of this version: CVE-2010-1622 and CVE-2013-6429 . If you look up the CVE descriptions or advisory, you will find: CVE-2010-1622: "SpringSource Spring Framework 2.5.x before 2.5.6.SEC02…" (and you can stop reading right there) CVE-2013-6429: No mention of 2.x on https://tanzu.vmware.com/security/cve-2013-6429 and according to the Spring Javadoc, the class was introduced in Spring 3.0. jremitz Could you clarify whether you did any research here and I missed something, or whether you just dumped a security scan result here?

          Jake Remitz added a comment -

          You're importing these utilities in your Jenkins artifact, right? I'm just looking to have them updated in your project. Presumably, there are newer versions of those libraries without the vulnerabilities. I'm looking to have an updated build (Cloudbees) that uses newer, "safer" versions or removes them if they were unnecessarily imported. Does that make sense? I'm not stating that you own these libraries, it's clear they don't. I'm aware they are Spring libraries, but you're choosing to build with those specific, outdated, and more importantly vulnerable versions which are getting flagged on security scans.

          We have to whitelist Jenkins because you don't have updated libraries. At the time of scan we are not installing 3rd party plugins yet either. Are you passing your own, internal security scans? Do you have specific libraries whitelisted that you can share so we can follow your examples to get the app deployed in our environment safely? However we can align would be great and easiest!

          Jake Remitz added a comment - You're importing these utilities in your Jenkins artifact, right? I'm just looking to have them updated in your project. Presumably, there are newer versions of those libraries without the vulnerabilities. I'm looking to have an updated build (Cloudbees) that uses newer, "safer" versions or removes them if they were unnecessarily imported. Does that make sense? I'm not stating that you own these libraries, it's clear they don't. I'm aware they are Spring libraries, but you're choosing to build with those specific, outdated, and more importantly vulnerable versions which are getting flagged on security scans. We have to whitelist Jenkins because you don't have updated libraries. At the time of scan we are not installing 3rd party plugins yet either. Are you passing your own, internal security scans? Do you have specific libraries whitelisted that you can share so we can follow your examples to get the app deployed in our environment safely? However we can align would be great and easiest!

          Daniel Beck added a comment -

          without the vulnerabilities

          As I explained, these vulnerabilities are false positive findings. Your security scanner is trash.

          Daniel Beck added a comment - without the vulnerabilities As I explained, these vulnerabilities are false positive findings. Your security scanner is trash.

          Jake Remitz added a comment -

          Actually, you didn't explain they were false positives. You said they were Spring's issue, not Cloudbees. You deflected and said it wasn't your problem.

          You're using Spring 2.5 or at least the time this issue was written, that's what you are using. It's clearly out of date. Rather than attacking the requestor, could you address the request? Is there an ETA for updating these libraries or Spring version? Could you maybe administer this ticket, relate it to another, possibly blocked issue to upgrade Spring? Or just address the open concern that the underlying framework is dated and if there's an ETA to do somethign about it? If you're not concerned about it - why aren't you concerned? I get you're probably tired of people asking for silly requests with little research. Apologies if this is the case, I did, at the time of writing my comment look into the maven file and libraries despite not being a developer. Heck, maybe our scanner is "trash" as you're accusing. I don't own it. I just want the problems to go away so the auditors are happy. Any help or explanation of that to make my life and possibly others better would be tremendously helpful. Thanks!

          Jake Remitz added a comment - Actually, you didn't explain they were false positives. You said they were Spring's issue, not Cloudbees. You deflected and said it wasn't your problem. You're using Spring 2.5 or at least the time this issue was written, that's what you are using. It's clearly out of date. Rather than attacking the requestor, could you address the request? Is there an ETA for updating these libraries or Spring version? Could you maybe administer this ticket, relate it to another, possibly blocked issue to upgrade Spring? Or just address the open concern that the underlying framework is dated and if there's an ETA to do somethign about it? If you're not concerned about it - why aren't you concerned? I get you're probably tired of people asking for silly requests with little research. Apologies if this is the case, I did, at the time of writing my comment look into the maven file and libraries despite not being a developer. Heck, maybe our scanner is "trash" as you're accusing. I don't own it. I just want the problems to go away so the auditors are happy. Any help or explanation of that to make my life and possibly others better would be tremendously helpful. Thanks!

          Daniel Beck added a comment -

          Actually, you didn't explain they were false positives

          I didn't use this term, true. Still, quoting my previous response:

          crypto-util is a library by the Jenkins project. The CVE points to Erlang Open Telecom Platform and is pretty obviously unrelated

          and

          "SpringSource Spring Framework 2.5.x before 2.5.6.SEC02…" (and you can stop reading right there)

          and

          the class was introduced in Spring 3.0.


          You deflected and said it wasn't your problem.  … It's clearly out of date. Rather than attacking the requestor, could you address the request?

          The outdated component is clearly a problem. It is however not a problem in the way you brought up – having these security vulnerabilities. I'm not attacking you, I point out that what you wrote specifically doesn't look like a problem.

          As far as I'm concerned (and since you keep bringing up my employer in an unrelated issue tracker, I'm not speaking on behalf of CloudBees), it's simply a matter of effort to benefit. It's almost certain that many plugins will break and require adaptation. And "not getting false positive security scanner findings" isn't the kind of benefit I would want to see for months of effort. In fact, if the issue description is correct and we'd have to update Groovy, it would almost certainly introduce new security vulnerabilities (via Script Security).

          Daniel Beck added a comment - Actually, you didn't explain they were false positives I didn't use this term, true. Still, quoting my previous response: crypto-util is a library by the Jenkins project. The CVE points to Erlang Open Telecom Platform and is pretty obviously unrelated and "SpringSource Spring Framework 2.5.x before 2.5.6.SEC02…" (and you can stop reading right there) and the class was introduced in Spring 3.0. You deflected and said it wasn't your problem.  … It's clearly out of date. Rather than attacking the requestor, could you address the request? The outdated component is clearly a problem. It is however not a problem in the way you brought up – having these security vulnerabilities. I'm not attacking you, I point out that what you wrote specifically doesn't look like a problem. As far as I'm concerned (and since you keep bringing up my employer in an unrelated issue tracker, I'm not speaking on behalf of CloudBees), it's simply a matter of effort to benefit. It's almost certain that many plugins will break and require adaptation. And "not getting false positive security scanner findings" isn't the kind of benefit I would want to see for months of effort. In fact, if the issue description is correct and we'd have to update Groovy, it would almost certainly introduce new security vulnerabilities (via Script Security).

          Jake Remitz added a comment -

          drats, should have had more coffee... EVERYONE has a cloudbees id. facepalm - sorry for the obvious confusion on my part.

          I never really expected this to be a quick thing, just hoping it would be fuel for the fire. I read the initial response as "deal with it" instead of something constructive. The issue is nearly 5 years old and it's still relevant (needing updates). So despite the months of effort, it's probably worth it to stay modern and supported across the board with various dependencies. Tech debt is just going to keep piling on. Oh well I suppose. Anyways... thanks for the insight. I'm not disagreeing with any of the above, but i'm hoping the initial response doesn't distract from the goal that there are underlying implications for not maintaining the framework. This is just one, however small.

          Jake Remitz added a comment - drats, should have had more coffee... EVERYONE has a cloudbees id. facepalm - sorry for the obvious confusion on my part. I never really expected this to be a quick thing, just hoping it would be fuel for the fire. I read the initial response as "deal with it" instead of something constructive. The issue is nearly 5 years old and it's still relevant (needing updates). So despite the months of effort, it's probably worth it to stay modern and supported across the board with various dependencies. Tech debt is just going to keep piling on. Oh well I suppose. Anyways... thanks for the insight. I'm not disagreeing with any of the above, but i'm hoping the initial response doesn't distract from the goal that there are underlying implications for not maintaining the framework. This is just one, however small.

          James Nord added a comment -

          so I guess we can close this now jglick

          James Nord added a comment - so I guess we can close this now jglick

          James Nord added a comment -

          James Nord added a comment - https://www.jenkins.io/blog/2020/11/10/spring-xstream/

          Jesse Glick added a comment -

          Yup, never saw this one.

          Jesse Glick added a comment - Yup, never saw this one.

            Unassigned Unassigned
            teilo James Nord
            Votes:
            5 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: