[JIRA] [core] (JENKINS-28687) spring version is ancient and not compatable with many new libraries

10 views
Skip to first unread message

teilo@java.net (JIRA)

unread,
Jun 2, 2015, 6:06:02 AM6/2/15
to jenkinsc...@googlegroups.com
James Nord created an issue
 
Jenkins / Bug JENKINS-28687
spring version is ancient and not compatable with many new libraries
Issue Type: Bug Bug
Assignee: Unassigned
Components: core
Created: 02/Jun/15 10:05 AM
Priority: Minor Minor
Reporter: James Nord

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.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

teilo@java.net (JIRA)

unread,
Jun 2, 2015, 6:07:01 AM6/2/15
to jenkinsc...@googlegroups.com
James Nord updated an issue
 
spring version (2.5.x) is ancient and not compatable with many new libraries
Change By: James Nord
Summary: spring version  (2.5.x)  is ancient and not compatable with many new libraries

dbeck@cloudbees.com (JIRA)

unread,
Jun 15, 2015, 12:25:01 PM6/15/15
to jenkinsc...@googlegroups.com
Daniel Beck commented on Bug JENKINS-28687
 
Re: spring version (2.5.x) is ancient and not compatable with many new libraries

At the same time, any upgrade of this will also be a breaking change for anything that already integrates, right?

teilo@java.net (JIRA)

unread,
Jun 15, 2015, 7:08:01 PM6/15/15
to jenkinsc...@googlegroups.com

Spring trieds to retain backwards compatability.

There are a few noteable exceptions, so any upgrade is not without risks

ethan.young@raytheon.com (JIRA)

unread,
Jan 22, 2019, 10:22:01 AM1/22/19
to jenkinsc...@googlegroups.com
Ethan Young updated an issue
 
Change By: Ethan Young
Priority: Minor Major
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

ethan.young@raytheon.com (JIRA)

unread,
Jan 22, 2019, 10:25:02 AM1/22/19
to jenkinsc...@googlegroups.com

ethan.young@raytheon.com (JIRA)

unread,
Jan 22, 2019, 10:25:02 AM1/22/19
to jenkinsc...@googlegroups.com
Ethan Young commented on Bug JENKINS-28687
 
Re: spring version (2.5.x) is ancient and not compatable with many new libraries

Upgrading the Spring framework will also resolve security issues. Specifically, CVE-2017-8046 is an expression language injection vulnerability in the Spring Data REST library v2.6.8 and earlier.

dbeck@cloudbees.com (JIRA)

unread,
Jan 22, 2019, 10:28:01 AM1/22/19
to jenkinsc...@googlegroups.com

Jake.Remitz@carlsonwagonlit.com (JIRA)

unread,
Apr 16, 2019, 10:22:06 AM4/16/19
to jenkinsc...@googlegroups.com

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.

Jake.Remitz@carlsonwagonlit.com (JIRA)

unread,
Apr 16, 2019, 10:37:02 AM4/16/19
to jenkinsc...@googlegroups.com
Jake Remitz edited a comment on Bug JENKINS-28687
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*.

dbeck@cloudbees.com (JIRA)

unread,
Mar 31, 2020, 7:02:05 AM3/31/20
to jenkinsc...@googlegroups.com

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.

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

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

jake.remitz@carlsonwagonlit.com (JIRA)

unread,
Mar 31, 2020, 10:15:03 AM3/31/20
to jenkinsc...@googlegroups.com

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!

dbeck@cloudbees.com (JIRA)

unread,
Mar 31, 2020, 10:21:02 AM3/31/20
to jenkinsc...@googlegroups.com

without the vulnerabilities

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

jake.remitz@carlsonwagonlit.com (JIRA)

unread,
Mar 31, 2020, 10:30:03 AM3/31/20
to jenkinsc...@googlegroups.com

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!

dbeck@cloudbees.com (JIRA)

unread,
Mar 31, 2020, 10:55:02 AM3/31/20
to jenkinsc...@googlegroups.com

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@carlsonwagonlit.com (JIRA)

unread,
Mar 31, 2020, 11:19:02 AM3/31/20
to jenkinsc...@googlegroups.com

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.

Reply all
Reply to author
Forward
0 new messages