Horton

Re: disabled SSL log_like tests

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

View thread View on postgr.es
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-09T00:15:24Z
Lists: pgsql-hackers

Attachments

Daniel Gustafsson <daniel@yesql.se> writes:
> Maybe the ssl_library function should return a hash with backend => 'OpenSSL'
> and library => <the actual implementation used>?

I don't love doing it exactly like that: seems like it adds notational
complexity for little gain.  Also, it forces ssl_library to expend
work detecting things the current caller may not care about.

I was thinking about just transposing the existing test down to the
backend layer, more or less as attached.  Not wedded to these names
of course.

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

Right.  I think the attached would be amenable to that.

Further down the road, it seems inevitable that we'll need to have a
way of detecting the SSL library version --- for example, assuming
the LibreSSL folk eventually fix their RSA-PSS code, we'll need a
version-dependent test.  That could be another new backend method,
I guess.

			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.