Re: disabled SSL log_like tests

Tom Lane <tgl@sss.pgh.pa.us>

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>
Date: 2025-05-09T14:03:51Z
Lists: pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
> On 9 May 2025, at 02:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Right.  I think the attached would be amenable to that.

> It will be a bit awkward to ask "are you libressl" if we ever add support for
> something not OpenSSL based, but we could always revisit should that happen.

I was imagining that unrelated backends would simply make the method
report constant-false.  But in any case, redesigning this in the light
of any future requirements doesn't seem like a big deal.  What I'm
mainly after for today is just to ensure that these various which-
library-is-it tests are visibly interconnected, so that we don't
forget to check them all when things change.

			regards, tom lane



Commits

  1. Skip RSA-PSS ssl test when using LibreSSL.

  2. Ooops ... add required configure support.

  3. Hack one ssl test case to pass with current LibreSSL.

  4. Centralize ssl tests' check for whether we're using LibreSSL.

  5. Re-enable SSL connect_fails tests, and fix related race conditions.

  6. Disable unstable test cases in src/test/ssl/t/001_ssltests.pl.