>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
