pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: vlsi (@vlsi) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: Re: [pgjdbc/pgjdbc] PR #4079: docs: spell out the proactive-security window in SECURITY.md
Date: Wed, 20 May 2026 12:35:07 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
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.
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: github://pgjdbc/pgjdbc
Cc: [email protected], [email protected]
Subject: Re: [pgjdbc/pgjdbc] PR #4079: docs: spell out the proactive-security window in SECURITY.md
In-Reply-To: <<[email protected]>>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox