Modernize core dependency json-lib library

[Bob Du]

As part of the core dependencies, json-lib has not been updated for a
decade and depends on an outdated version of commons-lang2.
https://github.com/jenkinsci/jenkins/pull/8996#issuecomment-2033276342

I have created a Jira issue for the modernization of json-lib, which
has been added to the Jira epic "Core and core component dependency
debt" as a part of it.
https://issues.jenkins.io/browse/JENKINS-72981
https://issues.jenkins.io/browse/JENKINS-68689

The following phased plan is proposed:

Step 1: Merge the exclusive dependency of json-lib, ezmorph, directly
into our forked json-lib repository. We plan to release it in a single
jar package in the future.
(Already create a PR: https://github.com/jenkinsci/json-lib/pull/8)

Step 2: Update the code to replace all uses of commons-lang2 with Java
native API.

Step 3: Rebuild the CI release process for json-lib and release a new version.

Thanks
Bob Du

[Basil Crow]

Hey Bob, thank you for proposing this!

Jenkins core delivers JSON-lib under the net.sf package namespace,
consumes it itself, and provides it to many consuming plugins. It
looks like Andres Almiray is still maintaining JSON-lib and EZMorph
over at https://github.com/kordamp/json-lib and
https://github.com/kordamp/ezmorph, but these new versions use the
org.kordamp package namespace and depend on Commons Lang 3 — both of
which go against our goal to avoid increasing core API surface area by
exposing additional third-party libraries.

Ultimately core needs to be able to parse JSON itself, and the Java
Platform does not provide a built-in way to do this. Under the current
architecture, where all core dependencies are exposed to plugins, that
means we can't avoid exposing at least _one_ JSON library to plugins:
the one used by core itself, which is currently JSON-lib under the
net.sf package namespace. Even if we did want to migrate core and
plugins to a newer version of JSON-lib or a different JSON library
(and I'm not sure we do), we'd have to continue to support JSON-lib
under the net.sf package namespace during the transition period at the
very least.

So your idea of cleaning up our old fork of (net.sf-based) JSON-lib to
at least avoid Commons Lang 2 sounds practical indeed in the short to
medium-term. At least that will allow us to proceed with cleaning up
Commons Lang, even if the JSON mess remains — a problem which can be
dealt with separately, if we ever need to deal with it at all. Another
argument in favor of this proposal is that it is no worse than the
current status quo, but a strict improvement in that it decreases
core's API surface area — without any risk of regression. These
advantages are not insignificant when dealing with such an old
codebase.

I could support this plan with one minor tweak. As I wrote in another
thread recently, I think modernizing the build and CI system should be
done before any other changes, because it is difficult to review and
test the other changes without a working build and CI system. In part
due to the success of the Jenkins project, the bar for software
development has been raised throughout the industry such that a modern
build and CI system is now considered table stakes. Accordingly, I
think this should be done first, and then the other changes you have
mentioned. So I would kindly request that you first prepare a PR to
update the build to use the latest parent POM and Jenkinsfile. Without
commit access to the repository in question, you won't be able to test
Jenkinsfile changes on ci.jenkins.io, but I can assist with testing
these changes using my permissions. Here are some other core
components that can be used as a reference:

https://github.com/jenkinsci/bridge-method-injector
https://github.com/jenkinsci/core-annotation-processors
https://github.com/jenkinsci/extensibility-api
https://github.com/jenkinsci/extras-memory-monitor
https://github.com/jenkinsci/jelly
https://github.com/jenkinsci/jenkins-test-harness
https://github.com/jenkinsci/jenkins-test-harness-htmlunit
https://github.com/jenkinsci/lib-access-modifier
https://github.com/jenkinsci/lib-annotation-indexer
https://github.com/jenkinsci/lib-crypto-util
https://github.com/jenkinsci/lib-file-leak-detector
https://github.com/jenkinsci/lib-mock-javamail
https://github.com/jenkinsci/lib-process-utils
https://github.com/jenkinsci/lib-support-log-formatter
https://github.com/jenkinsci/lib-symbol-annotation
https://github.com/jenkinsci/lib-task-reactor
https://github.com/jenkinsci/lib-test-annotations
https://github.com/jenkinsci/lib-version-number
https://github.com/jenkinsci/remoting
https://github.com/jenkinsci/stapler
https://github.com/jenkinsci/winstone

[Bob Du]

Thanks basil,

I agree with your idea. I will prepare another PR to modernize the CI system first.

Before that, I checked and compared the code and found that the fork dependency version currently in use should have been built and released from the rebase-2.4 branch, not master.
If you also confirm that this is the current situation, could you rename the rebase-2.4 branch to main or master branch, and set it as the default branch? And rename the current master to before-modernize-master-backup branch (or another name to archive it)?

[Jesse Glick]

On Wed, Apr 10, 2024 at 6:27 PM Basil Crow <m...@basilcrow.com> wrote:

Even if we did want to migrate core and plugins to […] a different JSON library […], we'd have to continue to support JSON-lib under the net.sf package namespace during the transition period at the very least.

I think it is worse than that, because jsonlib types are exposed in core API signatures. For example https://issues.jenkins.io/browse/JENKINS-67344 cannot be solved merely by switching to a reasonable parser, since you would still need to provide compatibility for https://javadoc.jenkins.io/hudson/model/UpdateSite.html#getJSONObject() and similar. So in the short term, being able to deliver patches to jsonlib would be helpful.

[Basil Crow]

On Thu, Apr 11, 2024 at 6:31 AM 'Jesse Glick' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
>
> I think it is worse than that

Note that I wrote "migrate core *and* plugins", which would mean
creating a new method that returns a different type and adjusting
consumers accordingly. If we were to upgrade to the latest
(org.kordamp-based) JSON-lib, we could possibly provide bridge methods
for the old package namespace, but otherwise consumers would need to
be changed more drastically to consume a different library's JSON
object. Yes, it is the worst category of Jenkins migrations, in the
same category or worse as the Jakarta EE servlet migration; but no, it
is not worse than what I wrote in my previous message.

[Basil Crow]

On Wed, Apr 10, 2024 at 7:50 PM Bob Du <ggb...@gmail.com> wrote:
>
> Before that, I checked and compared the code and found that the fork dependency version currently in use should have been built and released from the rebase-2.4 branch, not master.

I confirmed that by comparing the sources JAR on Artifactory to the
rebase-2.4 branch. I've swapped the branches as you suggested.

[Basil Crow]

CVE-2025-48924 increases the motivation to remove Commons Lang 2 from
Jenkins core. That cannot be done until core stops depending on it
(including via Json-Lib), as discussed in this thread, and until
plugins stop depending on core's copy. To track the latter I created
this spreadsheet:

https://docs.google.com/spreadsheets/d/1w6_QXUflt1GSTdQ1-WyWtVXewu99LuHuvr-0Hivoi7I/edit

[Verachten Bruno]

Basil,

Thank you for creating the spreadsheet to track the dependencies related to removing Commons Lang 2 from Jenkins core.

That will prove helpful!

Best wishes,

Bruno

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrL%3D3nOYG8nAOVVZofbXJcy65-%2B-E0Kd%3Da%2B06q9fa9WKA%40mail.gmail.com.

--

Bruno Verachten

[Winter, Markus]

Afaik core is not using commons-lang anymore. It is only included in core due to json-lib.

And given the almost 300 plugins that use commons-lang I think once json-lib is fixed we can remove it from core and have the commons-lang-api  plugin as an implied dependency. 

Can we make the Jenkins Security Scan look for usages of commons.lang and report them? 

---

From: jenkin...@googlegroups.com <jenkin...@googlegroups.com> on behalf of Verachten Bruno <goun...@gmail.com>
Sent: Wednesday, July 30, 2025 6:20 PM
To: jenkin...@googlegroups.com <jenkin...@googlegroups.com>
Subject: Re: Modernize core dependency json-lib library

 

To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/CACtV%3DdcdRBFQhs6QxQ5jEMLxf9Eei2Lg%3DRu1bzrGyUkweNrdLw%40mail.gmail.com.

[Basil Crow]

On Wed, Jul 30, 2025 at 10:30 AM 'Winter, Markus' via Jenkins
Developers <jenkin...@googlegroups.com> wrote:
>
> And given the almost 300 plugins that use commons-lang I think once json-lib is fixed we can remove it from core and have the commons-lang-api plugin as an implied dependency.

An implied dependency could work, but those tend to stick around a lot
longer and are more difficult to reason about and debug. For example,
I can foresee complaints (like ones we've had before) that a
hypothetical detached Commons Lang 2 plugin keeps getting installed
even after users remove it simply because they happened to install a
new plugin with an older baseline. Cleaner and simpler to remove the
dependency after migrating plugins, particularly given that its
presence on the classpath trips up security scanners.

When looking at plugins, I see two major categories: plugins that use
Commons Lang extensively (which can be migrated to version 3) and
plugins that use it only in a handful of places for extremely basic
functionality (e.g., checking if some string is null or empty, which
can easily be migrated to standard Java Platform functionality). Doing
a sweep of the ecosystem might be more work in the short term, but in
the long term it leaves the code in a better state and gets us more
quickly to a state where security scanners stop complaining about our
classpath.

[Winter, Markus]

I then suggest to stop the distribution of the commons-lang-api plugin.

It is not used by any plugin so far and we should avoid that anyone starts using it.

---

From: jenkin...@googlegroups.com <jenkin...@googlegroups.com> on behalf of Basil Crow <m...@basilcrow.com>
Sent: Wednesday, July 30, 2025 7:39 PM

To: jenkin...@googlegroups.com <jenkin...@googlegroups.com>
Subject: Re: Modernize core dependency json-lib library

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion visit https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fjenkinsci-dev%2FCAFwNDjpHFRW_sgeP9T%253DUba1g-gOuvB%253D7%253Db_0BDtysWjRS1Ya0A%2540mail.gmail.com&data=05%7C02%7Cm.winter%40sap.com%7C1ee0f7b0136b476db9dd08ddcf902162%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638894940148578435%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F2eusjzUcinDrJlCd9d7zKO4R1KsPuAqZ%2F5dV7wGrZ0%3D&reserved=0.

[Basil Crow]

I did a risk assessment of the various Apache Commons libraries we are
shipping in core.

---

commons-beanutils-1.11.0.jar
Used extensively by Stapler/Jelly and cannot be removed. We're on
version 1.11.0, which doesn't use Commons Lang 3; version 2.0.0-M2
uses Commons Lang 3. If Commons BeanUtils 2 were to become the only
secure release line, then we would be unable to upgrade without also
including Commons Lang 3 in core (or forking Commons BeanUtils 2 to
remove its dependency on Commons Lang 3).

commons-collections-3.2.2.jar
Used by core directly only in one outdated location, but used by core
extensively as a transitive dependency of Commons BeanUtils. The
current release doesn't use Commons Lang 3. If a future one did, the
same assessment applies as for Commons BeanUtils 2.

commons-codec-1.19.0.jar
Not used directly by core. The current release doesn't use Commons
Lang 3. If a future one did, we could remove this library from core
and turn it into a library plugin, rewriting usages in plugins to
either use the library plugin or the Java Platform (similar to what we
are currently doing for Commons Lang 2).

commons-fileupload2-2.0.0-M4.jar
Used by Stapler and Core. The current release doesn't use Commons Lang
3. If a future one did, we could possibly rewrite the code to use
standard Java Platform functionality, but that would be tricky due to
compatibility constraints.

commons-io-2.20.0.jar
Used extensively by core and plugins. The current release doesn't use
Commons Lang 3. If a future one did, we could possibly rewrite the
code to use standard Java Platform functionality, but that be a large
effort.

We're also shipping our own fork of Jelly/JEXL, but there is no risk
there because we have full control over it.

---

Overall, I think the biggest risk for us is Commons BeanUtils 2. It
would be desirable if we could advocate for Commons BeanUtils 2 to
drop its Commons Lang 3 dependency. We previously (unsuccessfully)
attempted to advocate for Commons Compress to do the same. If such an
advocacy attempt for Commons BeanUtils 2 is similarly unsuccessful, we
might have to eventually add Commons Lang 3 to core, or else fork
Commons BeanUtils 2 to remove its dependency on Commons Lang 3.

[Bob Du]

In fact, I noticed that we have already included spring-beans as an indirect dependency due to our use of spring-security-web. Is it possible for us to fully replace the usage of commons-beanutils with spring-beans?

[Basil Crow]

On Mon, Aug 25, 2025 at 8:15 PM Bob Du <ggb...@gmail.com> wrote:
>
> In fact, I noticed that we have already included spring-beans as an indirect dependency due to our use of spring-security-web. Is it possible for us to fully replace the usage of commons-beanutils with spring-beans?

Perhaps, if it can be done without regressions to functionality or
performance (as demonstrated by, at minimum, PCT and ATH test runs).
The Spring project is more closely aligned with our dependency
requirements than Apache Commons.

[Basil Crow]

On Fri, Aug 1, 2025 at 9:19 AM Basil Crow <m...@basilcrow.com> wrote:
>
> Overall, I think the biggest risk for us is Commons BeanUtils 2. It
> would be desirable if we could advocate for Commons BeanUtils 2 to
> drop its Commons Lang 3 dependency. We previously (unsuccessfully)
> attempted to advocate for Commons Compress to do the same. If such an
> advocacy attempt for Commons BeanUtils 2 is similarly unsuccessful, we
> might have to eventually add Commons Lang 3 to core, or else fork
> Commons BeanUtils 2 to remove its dependency on Commons Lang 3.

I proposed such a change to Commons BeanUtils, but it was vetoed. In
the medium to long term, I think we will need to fork Commons