check_ssl_key_file_permissions should be in be-secure-common.c
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:t38483psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 08: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 t38483_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 t38483_1 && git checkout t38483_1Patchset v1 (message #1) is on t38483_1
Peter, Daniel,
The recent commit 8a3d9425 which has introduced SSL passphrase support
has also added be-secure-common.c, which works similarly to
fe-secure-common.c but for the backend.
I was just reading this code area, when I noticed that
check_ssl_key_file_permissions is called by be-secure-openssl.c but the
routine is defined in be-secure.c, causing some back-and-forth between
the two files.
It seems to me that this routine should be logically put into
be-secure-common.c so as future SSL implementations can use it. This
makes the code more consistent with the frontend refactoring that has
happened in f75a959. I would not have bothered about this refactoring
if be-secure-openssl.c did not exist yet, but as it does I think that we
should bite the bullet, and do that for v11 so as a good base is in
place for the future.
A patch is attached.
Thanks,
--
Michael
On 4/2/18 02:51, Michael Paquier wrote:
It seems to me that this routine should be logically put into
be-secure-common.c so as future SSL implementations can use it. This
makes the code more consistent with the frontend refactoring that has
happened in f75a959. I would not have bothered about this refactoring
if be-secure-openssl.c did not exist yet, but as it does I think that we
should bite the bullet, and do that for v11 so as a good base is in
place for the future.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services