public inbox for [email protected]
help / color / mirror / Atom feedFrom: Daniel Gustafsson <[email protected]>
To: Tom Lane <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Jacob Champion <[email protected]>
Subject: Re: disabled SSL log_like tests
Date: Thu, 8 May 2025 22:48:27 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+hUKGJkUJAwckjBr-=B9oUdDgjSEH+3njd__OnPoPuAtze3Qg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
> On 8 May 2025, at 22:24, Tom Lane <[email protected]> wrote:
>
> Daniel Gustafsson <[email protected]> writes:
>> On 8 May 2025, at 15:49, Tom Lane <[email protected]> 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
view thread (30+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: disabled SSL log_like tests
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox