Message-ID: From: "vlsi (@vlsi)" To: "pgjdbc/pgjdbc" Date: Wed, 20 May 2026 12:35:07 +0000 Subject: Re: [pgjdbc/pgjdbc] PR #4079: docs: spell out the proactive-security window in SECURITY.md In-Reply-To: References: List-Id: X-GitHub-Author-Login: vlsi X-GitHub-Comment-Id: 4498439114 X-GitHub-Comment-Type: issue_comment X-GitHub-Edited-At: 2026-05-20T12:43:42Z X-GitHub-Issue: 4079 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/4079#issuecomment-4498439114 Content-Type: text/plain; charset=utf-8 Thanks for the careful read — let me untangle one thing up front, because I think the central claim in this PR reads stronger than it actually is. **The unit of support is a release *line*, not an individual release.** "Within a line we keep N tags alive" is exactly the thing we *don't* do — only the latest tag on each line gets backports. When a CVE lands and N lines are still in the proactive window, we ship one patch *per line*, on that line's own minor (e.g. CVE-2024-1597 → `42.7.2`, `42.6.1`, `42.5.5`, `42.4.4`, `42.3.9`, `42.2.28`, `42.2.28.jre7`). That's not new behaviour the PR is asking for — it's the de-facto practice the project has been running for years; the PR just puts a number on "for how long". Visually, "many concurrent supported lines" looks like this rather than the "10 versions in flight" framing: ```mermaid %%{init: {'gantt': {'displayMode': 'compact'}}}%% gantt title pgJDBC release lines under "5 years past successor's .0" dateFormat YYYY-MM-DD axisFormat %Y section 42.2.x 42.2.x development :done, 2018-01-17, 2021-10-18 Security backports :crit, 2021-10-18, 2026-10-18 section 42.3.x 42.3.x development :done, 2021-10-18, 2022-06-09 Security backports :crit, 2022-06-09, 2027-06-09 section 42.4.x 42.4.x development :done, 2022-06-09, 2022-08-24 Security backports :crit, 2022-08-24, 2027-08-24 section 42.5.x 42.5.x development :done, 2022-08-24, 2023-03-17 Security backports :crit, 2023-03-17, 2028-03-17 section 42.6.x 42.6.x development :done, 2023-03-17, 2023-11-20 Security backports :crit, 2023-11-20, 2028-11-20 section 42.7.x (current) 42.7.x development :active, 2023-11-20, 2026-05-20 ``` At any given moment **exactly one line is under active development**; the rest sit in a security-only tail. The matrix's nine rows are six lines (42.7.x carries two segments because of the PostgreSQL 9.1 floor bump, and 42.2.x carries two classifier rows — `.jre6` / `.jre7` — for the artefacts that already exist on Maven Central). A few specific responses: 1. **"users really should be using the latest version"** — agreed for the development case, and we already say so on the compatibility page. The proactive window is for the cases where that advice doesn't reach: downstream packagers whose own dependency policy forbids minor bumps in a patch release (Spring Boot is the canonical example), enterprise CI/CD that needs a CVE patch on the pinned minor before a planned upgrade, etc. Telling those users "upgrade to the latest minor or wait" is the same answer as "no security fix". 2. **"5 years feels long"** — 5y is the same window [PostgreSQL itself](https://www.postgresql.org/support/versioning/) uses for each major release. A driver whose support is shorter than upstream's would systematically leave users in the gap where their server is still under PG community support but their JDBC client isn't — which contradicts what users reasonably expect from a database driver. Empirically pgJDBC has been operating in that ballpark already: 42.2.x was still receiving CVE patches in 2024, well past `.0 + 3y`. 3. **Node.js-style LTS with a single supported line** — interesting, but it's *more restrictive* than what we currently do, not less. Under "only one in-support line", the CVE-2024-1597 fan-out above would not have shipped: Spring Boot users on 42.6.x would have been told to upgrade, which their own policy disallows. I'm happy to discuss LTS as a separate proposal, but I'd want it as a deliberate tightening, not as a side-effect of this PR. (And if we do tighten, we should answer "what's the plan for Spring Boot users on a pinned older minor when the next CVE drops?" before we ship.) 4. **JDK 6/7** — the `.jre6` / `.jre7` rows in the matrix are descriptive, not prescriptive: they document that `42.2.29.jre7` and `42.2.27.jre6` already exist on Maven Central. Dropping the *artefacts* (i.e. unpublishing or marking them stale) is a separate decision from how the matrix renders, and I'm fine doing that in a follow-up if there's agreement.