Horton

Re: Refactor SSL test framework to support multiple TLS libraries

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andrew Dunstan <andrew@dunslane.net>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-01T01:02:52Z
Lists: pgsql-hackers 
On Wed, Mar 31, 2021 at 10:43:00AM +0900, Michael Paquier wrote:
> Jacob has just raised this as an issue for an integration with NLS,
> because it may be possible that things fail with "SSL error" but a
> different error pattern, causing false positives:
> https://www.postgresql.org/message-id/e0f0484a1815b26bb99ef9ddc7a110dfd6425931.camel@vmware.com
> 
> I agree that those matches should be much more picky.  We may need to
> be careful across all versions of OpenSSL supported though :/

As I got my eyes on that, I am going to begin a new thread with a patch.

> With all the comments addressed, with updates to use a single scalar
> for all the connection strings and with a proper indentation, I finish
> with the attached.  Does that look fine?

Hearing nothing, I have applied this cleanup patch.  I am not sure if
I will be able to tackle the remaining issues, aka switching
SSLServer.pm to become an OO module and plug OpenSSL-specific things
on top of that.
--
Michael

Commits

  1. Move some client-specific routines from SSLServer to PostgresNode

  2. Stop requiring an explicit return from perl subroutines