pgjdbc/pgjdbc GitHub issues and pull requests (mirror)  

help / color / mirror / Atom feed

From: 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: Thu, 21 May 2026 12:49:29 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

On the signing isolation point, agreed, that's a real, separable win. Today the GPG signing key ends up materialised into the Gradle build, which means every plugin and every test dependency on the classpath is in a position to read it. Pulling signing into an isolated CI job with a narrow, audited software bill of materials would meaningfully shrink that attack surface. I'd back a refactor on that ground alone.

Where I'd push back is on the claim that decoupling pre-empts the Sonatype-availability concern Dave raised. Whatever pipeline talks to Central still needs the same auth/URL change when OSSRH retires — a decoupled GHA + shell + publication-tool stack inherits that update just as the current Gradle config would. The refactor relocates the maintenance, it doesn't eliminate it. (And patches to back branches usually don't touch the build system anyway; the case where decoupling actually saves work is also the case where the decoupled pipeline itself needs updating.)

---

Stepping back, though. Back to the PR itself.

The policy isn't new: pgJDBC has been shipping multi-line CVE backports for years (CVE-2024-1597 landed on 42.7.2 / 42.6.1 / 42.5.5 / 42.4.4 / 42.3.9 / 42.2.28 / 42.2.28.jre7). What's been missing is an explicit answer to "for how long?". The PR just puts a number on it: 5 years past the next minor's .0, anchored to PostgreSQL's own 5-year support cycle so the driver doesn't lag the server.

Publishing and signing isolation, Sonatype migration, build/publish decoupling is real but separate: how we ship vs for how long. Move it to a follow-up issue? Happy to open one and link back.

Does 5y past next minor's .0 look right? Anything blocking on the formalisation itself?

view thread (10+ messages)

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