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), October 22, 2026 at 09:06 AM.
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
<div><div>I also like the concept of .libprc. But if we think about it within the current state of configuration: let's say the user doesn't want to specify a CRL file, even in the default location (~/.postgresql/root.crl), we, as the client-side of PostgreSQL, have no right to refuse a connection to the database server. In that case, would it be correct to log that the user didn't specify a CRL file (even in (~/.postgresql/root.crl))?</div><div>The idea of the patch is to ensure that the client-side performs stricter configuration checking for CRL files than it currently does.</div><div> </div><div>--</div><div>Michael</div></div><div><br /></div><div><br /></div><div>----------------</div>
<div>Кому: Михаил Купцов (mr.cuptsov2018@yandex.ru);<br /></div>
<div>Копия: pgsql-hackers@lists.postgresql.org;<br /></div>
<div>Тема: Changing client-side behavior regarding Certificate Revocation Lists (CRL);<br /></div>
<div>25.08.2026, 15:08, "Daniel Gustafsson" <daniel@yesql.se>:<br /></div>
<blockquote><blockquote class="210e7a848e8fcb45wmi-quote"> On 24 Aug 2026, at 17:34, Михаил Купцов <<a href="mailto:mr.cuptsov2018@yandex.ru">mr.cuptsov2018@yandex.ru</a>> wrote:<br /></blockquote><p><br /></p><blockquote class="210e7a848e8fcb45wmi-quote"> I would like to propose a different approach regarding the client side behavior<br /> in terms of working with the list of revoked certificates. The problem that<br /> was discovered is that if a user, using psql, accidentally specifies an<br /> incorrect path to a crl file or crl directory, the client part of Postgres<br /> ignores the user's error and connects the client to the database whose<br /> certificate the client would, in theory, want to check whether the database<br /> server certificate has been revoked.<br /></blockquote><p><br /><br />I'm sympathetic to the idea of helping the user detect misconfiguration.<br />However, I wonder how common it is to have a "local default" filename<br />configured in apps which may or may not be present. If those users all of a<br />sudden cannot connect after an upgrade then we didn't really improve anything.<br /><br />Also, with this patch, users who have placed their CRL to match the default CRL<br />file location (~/.postgresql/root.crl) won't get an error if that file is<br />missing even if their intention was to use that file.<br /><br />I think a stricter CRL policy would need another trigger.<br /><br /></p><span class="f55bbb4eeef208e8wmi-sign">-- <br />Daniel Gustafsson<br /></span></blockquote>
On Wed, Aug 26, 2026 at 7:00 AM Михаил Купцов <mr.cuptsov2018@yandex.ru> wrote:
But if we think about it within the current state of configuration:
(We can think about it that way, but I'm not sure it makes sense to
split the difference between the current unhelpful behavior and a new
behavior that must break compatibility in some form anyway. Maybe we
could just implement the desired behavior with a clean break instead;
that's why I mentioned libpqrc.)
The idea of the patch is to ensure that the client-side performs stricter configuration checking for CRL files than it currently does.
Right, but since Daniel pointed out that this isn't a straight upgrade
in behavior, I don't think it necessarily gets the benefit of an
"incremental improvement" pass.
--Jacob