Re: Out-of-tree certificate interferes ssltest

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
Cc: daniel(at)yesql(dot)se, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Out-of-tree certificate interferes ssltest
Date: 2022-03-17 08:05:10
Message-ID: 20220317.170510.1335689533199004810.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 17 Mar 2022 16:22:14 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Thu, Mar 17, 2022 at 02:59:26PM +0900, Michael Paquier wrote:
> > In both cases, enforcing sslcrl to a value of "invalid" interferes
> > with the failure scenario we expect from sslcrldir. It is possible to
> > bypass that with something like the attached, but that's a kind of
> > ugly hack. Another alternative would be to drop those two tests, and
> > I am not sure how much we care about these two negative scenarios.
>
> Actually, there is a trick I have recalled here: we can enforce sslcrl
> to an empty value in the connection string after the default. This
> still ensures that the test won't pick up any SSL data from the local
> environment and avoids any interferences of OpenSSL's
> X509_STORE_load_locations(). This gives a much simpler and cleaner
> patch.
>
> Thoughts?

Ah! I didn't have a thought that we can specify the same parameter
twice. It looks like clean and robust. $default_ssl_connstr contains
all required options in PQconninfoOptions[].

The same method worked for 003_sslinfo.pl, too. (of course).

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-03-17 08:07:37 Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Previous Message Bharath Rupireddy 2022-03-17 07:55:35 Re: pg_walinspect - a new extension to get raw WAL data and WAL stats