Worth noting: since this proposal requires changes to both Maven coordinates and Java package, it could be done as a fork. It would be straight-forward for someone to fork and publish their own "just Strings" library, for instance. And if I needed less than that in one of my projects, I'd be sorely tempted to just copy and paste the code into some package private location so I had full control of what I was shipping and depending on.
On Thu, Oct 30, 2025 at 5:50 AM Vladimir Sitnikov <[email protected]> wrote: > > Hi all, > > Following the “Branch protection rules (CTR-style)” thread, > I’d like to spin off a separate discussion about micro-modularizing some > Commons libraries > to reduce CVE blast radius and dependency weight. > > Motivation (real-world pain): > > As Sebb noted, unused classes shouldn’t affect runtime, however > vulnerability scanners flag artifacts, > not “used classes”. > In practice teams must upgrade/patch even when only a tiny part is > affected; proving non-impact is often harder than bumping or excluding. > > Mere presence of a vulnerable class on the classpath can widen attack > surface > (e.g., unsafe deserialization paths + a vulnerable helper available to the > attacker). > > Recent examples show cross-bleed: projects that depend on > commons-compress:1.25.0 saw multiple CVEs > (CVE-2024-26308 Pack200 OOM, CVE-2024-25710 DUMP DoS) and also pulled in > commons-lang3 where ClassUtils CVE-2025-48924 then arrives transitively. > A modular layout like commons-pack200, commons-dump, commons-stringutils, > commons-arrayutils, etc., > would let consumers pick only what they need and limit exposure. > > Concrete proposal (small, testable): > > Pilot a commons-stringutils4 artifact containing only StringUtils and > Strings (and minimal shared internals if any). > Use org.apache.commons.stringutils4 package so it could co-exist with the > current commons-lang3. > > The existing commons-lang3 could depend on commons-stringutils4 so > lang3.StringUtils could delegate all the methods to > stringutils4.StringUtils. > > This would keep full backward compatibility for commons-lang3, and it would > avoid code duplication. > It would give users the ability to pull only StringUtils. > > Questions for the community: > > Are folks open to a pilot micro-module (commons-stringutils) released from > the lang repo? > Any hard blockers you see? > > Success criteria: adoption by projects that currently shade/extract > StringUtils; fewer CVE flags for users that don’t pull the rest of lang3. > For instance, even commons-compress runtime seem to > require just stringtuils and arrayutils. > > If there’s interest, I can draft a PR with commons-stringutils4. > > Thanks, > Vladimir -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
