ssl_library parameter
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:t38939psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 08:16 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 t38939_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 t38939_1 && git checkout t38939_1Patchset v1 (message #1) is on t38939_1
Extracted from the GnuTLS thread/patch, here is a patch to add a
server-side read-only parameter ssl_library, which currently reports
either 'OpenSSL' or an empty string, depending on what SSL library was
built with. This is analogous to the libpq function call
PQsslAttribute(conn, "library"), but there was no equivalent
functionality on the server side.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 26 Jun 2018, at 11:06, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
Extracted from the GnuTLS thread/patch, here is a patch to add a
server-side read-only parameter ssl_library, which currently reports
either 'OpenSSL' or an empty string, depending on what SSL library was
built with. This is analogous to the libpq function call
PQsslAttribute(conn, "library"), but there was no equivalent
functionality on the server side.
Looks good to me, +1
cheers ./daniel
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
Extracted from the GnuTLS thread/patch, here is a patch to add a
server-side read-only parameter ssl_library, which currently reports
either 'OpenSSL' or an empty string, depending on what SSL library was
built with. This is analogous to the libpq function call
PQsslAttribute(conn, "library"), but there was no equivalent
functionality on the server side.
(1) I'm not really clear why we need this. GUC variables aren't free.
(2) Are there security issues with exposing this info to everybody?
regards, tom lane
On 6/26/18 17:48, Tom Lane wrote:
(1) I'm not really clear why we need this. GUC variables aren't free.
(2) Are there security issues with exposing this info to everybody?
This functionality was requested in the threads about GnuTLS and other
SSL implementations so that users/admins can determine which SSL
settings are applicable.
I'm not sure about the security impact. We do expose all the other
ssl_* settings to ordinary users, so if users want to see whether the
server is misconfigured or something like that, they can already do
that. I think in the context of an SSL connection, the server is not
supposed to be the adversary of the client, so if the server can provide
more information about what it's doing to protect the client's
information, then the better.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 26/06/2018 11:49, Daniel Gustafsson wrote:
Extracted from the GnuTLS thread/patch, here is a patch to add a
server-side read-only parameter ssl_library, which currently reports
either 'OpenSSL' or an empty string, depending on what SSL library was
built with. This is analogous to the libpq function call
PQsslAttribute(conn, "library"), but there was no equivalent
functionality on the server side.Looks good to me, +1
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services