Changing client-side behavior regarding Certificate Revocation Lists (CRL)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253532psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 25, 2026 at 03:47 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253532_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253532_1 && git checkout t253532_1Patchset v1 (message #1) is on t253532_1
On 24 Aug 2026, at 17:34, Михаил Купцов <mr.cuptsov2018@yandex.ru> wrote:
I would like to propose a different approach regarding the client side behavior
in terms of working with the list of revoked certificates. The problem that
was discovered is that if a user, using psql, accidentally specifies an
incorrect path to a crl file or crl directory, the client part of Postgres
ignores the user's error and connects the client to the database whose
certificate the client would, in theory, want to check whether the database
server certificate has been revoked.
I'm sympathetic to the idea of helping the user detect misconfiguration.
However, I wonder how common it is to have a "local default" filename
configured in apps which may or may not be present. If those users all of a
sudden cannot connect after an upgrade then we didn't really improve anything.
Also, with this patch, users who have placed their CRL to match the default CRL
file location (~/.postgresql/root.crl) won't get an error if that file is
missing even if their intention was to use that file.
I think a stricter CRL policy would need another trigger.
--
Daniel Gustafsson
On Tue, Aug 25, 2026 at 1:08 AM Daniel Gustafsson <daniel@yesql.se> wrote:
I think a stricter CRL policy would need another trigger.
More fuel for the fire of a .libpqrc, maybe?
--Jacob
On 25 Aug 2026, at 17:24, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
On Tue, Aug 25, 2026 at 1:08 AM Daniel Gustafsson <daniel@yesql.se> wrote:
I think a stricter CRL policy would need another trigger.
More fuel for the fire of a .libpqrc, maybe?
That could certainly be a trigger. I was also thinking around how we have a
set of sslmodes which cover the usecases of yesteryear with less options for
todays world of security hardening, but .libpqrc is likely a better fit here.
--
Daniel Gustafsson