From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: Thomas Munro <thomas.munro@gmail.com>,
        Andrew Dunstan <andrew@dunslane.net>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
        Jacob Champion <jacob.champion@enterprisedb.com>
Subject: Re: disabled SSL log_like tests
In-reply-to: <2C91E50A-BBBF-4863-8582-6BF2C645CCC1@yesql.se>
References: <984fca80-85a8-4c6f-a5cc-bb860950b435@dunslane.net>
 <2199758.1744901785@sss.pgh.pa.us>
 <1ce11d3f-624c-4003-a032-1b10cc138305@dunslane.net>
 <2814408.1745005558@sss.pgh.pa.us> <2859105.1745015195@sss.pgh.pa.us>
 <1120735.1745350422@sss.pgh.pa.us>
 <CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com>
 <3058990.1746485124@sss.pgh.pa.us> <3227092.1746580691@sss.pgh.pa.us>
 <CA+hUKGJkUJAwckjBr-=B9oUdDgjSEH+3njd__OnPoPuAtze3Qg@mail.gmail.com>
 <3248136.1746592452@sss.pgh.pa.us>
 <3004EFB2-8FFA-429A-AC5E-E3F40E002A94@yesql.se>
 <3320404.1746633879@sss.pgh.pa.us>
 <8E3E58BF-CC99-4C45-9FB8-3BA83AA6FDC8@yesql.se>
 <51363.1746646179@sss.pgh.pa.us>
 <8293D36E-8027-4DB8-AB41-5EA2C2A9A788@yesql.se>
 <80137.1746654871@sss.pgh.pa.us>
 <D9A0285C-D051-4E6F-B9F0-09CE3282EA54@yesql.se>
 <182014.1746712177@sss.pgh.pa.us>
 <2C91E50A-BBBF-4863-8582-6BF2C645CCC1@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Thu, 08 May 2025 17:05:20 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <222847.1746735871.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 May 2025 16:24:31 -0400
Message-ID: <222848.1746735871@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/222848.1746735871%40sss.pgh.pa.us>
Precedence: bulk

Daniel Gustafsson <daniel@yesql.se> writes:
> On 8 May 2025, at 15:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I was feeling itchy about having two copies of code that looks none
>> too set-in-stone.  Maybe we should just do that.  Any preferences
>> on the API?

> There is already SSL::Server::ssl_library() which returns the underlying
> library, but it's not smart enough to differentiate between which flavou=
r of
> OpenSSL compatible library is being used (OpenSSL, Libressl, BoringSSL e=
tc) as
> it's only returning a hardcoded string as of now.  My plan was to expand=
 that
> at some point.

Hm.  There is this bit in 001_ssltests.pl:

my $result =3D $node->safe_psql('postgres', "SHOW ssl_library");
is($result, $ssl_server->ssl_library(), 'ssl_library parameter');

which would break.  Admittedly that's not a very exciting test,
so I wouldn't feel bad about dropping it, but maybe someone else
would.

Also, it seems like ssl_library is mainly intended to distinguish
which "backend" module is in use, so having the one string "OpenSSL"
seems to match up with the one backend "OpenSSL.pm".  What we're
talking about here feels like a finer subdivision.  I'm not quite
sure how it ought to fit into that "backend" structure.

We could deal with the RSA-PSS issue pretty cleanly by inventing a
backend method "supports_rsa_pss", but the other thing we're trying
to hack around doesn't seem like it has such a clean definition.

			regards, tom lane