> On 8 May 2025, at 22:24, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <dan...@yesql.se> writes:
>> On 8 May 2025, at 15:49, Tom Lane <t...@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
