Re: disabled SSL log_like tests

> On 8 May 2025, at 22:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> 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 flavour of
>> OpenSSL compatible library is being used (OpenSSL, Libressl, BoringSSL etc) 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 = $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.

I have no problems dropping that, it's rather uninteresting.

> 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.

The backend concept was mostly intended to match up with the underlying library.
It get's a bit murky as OpenSSL tough since it's a library, but also a popular API
compatibility target implemented by multiple libraries (Libressl, Boringssl,
Wolfssl come to mind).

Maybe the ssl_library function should return a hash with backend => 'OpenSSL'
and library => <the actual implementation used>?  Then the test author can
decide which level of compatibility they want?  If we were to end up with a
Libressl libtls implementation in libpq we'd still have to test with Libressl
against the OpenSSL compat layer in libssl since it could act as both.  Not a
bridge we have to cross today but might be worth at least keeping in mind when
designing something to not make it impossible in the future.

--
Daniel Gustafsson