Hi, I think that it would still be valuable for Commons to publish a clear document outlining the expected CVE-support and EOL timelines for each Commons component / version. This doesn’t commit the PMC to supporting any particular branch indefinitely, but it does give users predictable expectations.
Many frustrations stem not from the policy itself but from the absence of an explicit policy. Even a simple table listing “supported until”, “security fixes only until”, or “EOL as of” for each major line would help downstream consumers plan upgrades and avoid surprises. The actual code changes involved in these CVE fixes are very small, creating a maintenance fork is not only possible but straightforward: update the package metadata, apply the patch, publish under a new groupId, and consumers who need stability can depend on that fork without touching anything else in their codebase. This avoids placing an ongoing release burden on the PMC while still giving downstream users an immediate, practical path forward. It is also completely consistent with how open-source ecosystems have historically handled diverging maintenance expectations; when a subset of users needs long-term stability and the core project cannot or does not wish to support it, a lightweight compatibility fork is a normal and accepted solution. If the community or individual users prefer not to publish a separate artifact, they can simply monkey-patch the existing JAR at build time or during packaging. We do this in TomEE for transient eol dependencies: take an existing binary, inject or replace specific classes, and produce a patched artifact without modifying the upstream release process at all. For tiny, self-contained fixes like the one under discussion, this can be a very low-overhead approach that keeps users secure without requiring any changes on the PMC side (but might confuse security scanners of course). Just my 2 cents from the side gallery (not involved in commons, but a user ;-) ) Richard > Am 14.11.2025 um 07:35 schrieb Vladimir Sitnikov > <[email protected]>: > >> This is the normal expectation for software patching. CVE -> patch release >> -> update build -> exposure gone / scanning tools happy. > > +1 > >> allowing for some overlap, but not perpetual >> In some cases, we may decide to support n - 1 for more than a year > > Frankly, "security fixes for 1 year only" is very weak. > > For pgjdbc, we go for "perpetual security fixes" policy: > https://github.com/pgjdbc/pgjdbc/security/policy > Canonical recently expanded Ubuntu's security fixes to 15 years. > > I do not think "n-k" is right unless there's a strict mapping of n to > calendar dates since users can't predict > when n+1 releases. > > From the end-user's perspective, it would be better to have something like > "you might expect security patches for Y years without code changes" > >> Given our limited resources, I think it makes sense to >> generally limit support to the latest major version (allowing for some >> overlap, but not perpetual) > > I would like to hear **practical** limits when you say "limited resources". > > What is the exact maintenance cost? Can you quantify it? > > I went ahead and provided a patch for 2.x: > https://github.com/vlsi/commons-lang/tree/lang-2.6-CVE-2025-48924 > The build succeeds with Java 8, the tests pass, the change is minimal. > > The only remaining bit is to review it and release a version. > Unfortunately, I can't help you with the release stuff as I am not even a > committer on Commons. > If I were a committer I could volunteer to be a release manager (I'm not > sure non-committers can be RMs). > > I do not see practical reasons to block security patches for the past > branches > especially when it takes just to vote and publish the release (the fix is > contributed, etc). > > It would make a lot of things easier for the consumers at a small cost from > the PMC. > > I see you are afraid of a "storm of CVE release requests for the old > codebase", however, I do not buy that. > I've been a co-maintainer for pgjdbc for 10 years already. > The library is quite popular, and there's no storm of "please fix CVE in > 20-y-o version" requests. > >> To be clear, I think we *are* doing a good job of addressing >> vulnerabilities in current versions and the "fixes will not require client >> code changes" part of (*) is hard to satisfy > > Frankly, it there are still flaws in Commons way of handling CVEs. > CVE-2025-48924 was fixed **only** in 3.18.0 > The users of 3.0 (released in 2011) have to go though 14 years worth of > minor upgrades. > Sure there are good bugfixes there, however, there might be breaking > behavior changes (both intentional and not) > which is extremely unwanted when addressing security issues. > > For instance, commons-lang3:3.0 targets Java 1.5. > The upgrade to commons-lang3:3.18.0 would require users to upgrade Java to > 1.8, > and bump their bytecode handling libraries which might be complicated. > > commons-3:3.8 (released in 2018) targets Java 1.7, so upgrading to 3.18.0 > might require code changes as well. > > The newer minor version deprecate methods, and it might break the builds > for those who use "fail the build on warnings". > Ideally, when a CVE releases, there should be **patch** versions available > with security fixes. > If you release security fixes for the latest-latest release only, then it > is really tough for the consumers > to bump through the remaining minor versions. > > Here's an example in pgjdbc: > https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-24rp-q3w6-vc56 > We published a patch fix for **every** minor version, so the clients could > bump immediately with full bug-to-bug compatibility. > See more details here: > https://github.com/pgjdbc/pgjdbc/discussions/3201#discussioncomment-9091742 > > commons-lang3:3.18.0 released just a few months ago. > What if a new CVE arrives? Would you release 3.18.1 or would you force > everybody to upgrade to the latest 3.x? > > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
