From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Out-of-tree certificate interferes ssltest |
Date: | 2022-03-18 01:02:52 |
Message-ID: | YjPaPPdliVMAz3hC@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 17, 2022 at 02:28:49PM +0100, Daniel Gustafsson wrote:
> One small concern though. This hunk:
>
> +my $default_ssl_connstr = "sslkey=invalid sslcert=invalid sslrootcert=invalid sslcrl=invalid sslcrldir=invalid";
> +
> $common_connstr =
> - "user=ssltestuser dbname=trustdb sslcert=invalid hostaddr=$SERVERHOSTADDR host=common-name.pg-ssltest.test";
> + "$default_ssl_connstr user=ssltestuser dbname=trustdb hostaddr=$SERVERHOSTADDR host=common-name.pg-ssltest.test";
>
> ..together with the following changes along the lines of:
>
> - "$common_connstr sslrootcert=invalid sslmode=require",
> + "$common_connstr sslmode=require",
>
> ..is making it fairly hard to read the test and visualize what the connection
> string is and how the test should behave. I don't have a better idea off the
> top of my head right now, but I think this is an area to revisit and improve
> on.
I agree that this makes this set of three tests harder to follow, as
we expect a root cert to *not* be set locally. Keeping the behavior
documented in each individual string would be better, even if that
duplicates more the keys in those final strings.
Another thing that Horiguchi-san has pointed out upthread (?) is 003,
where it is also possible to trigger failures once the environment is
hijacked. The attached allows the full test suite to pass without
issues on my side.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
ssltest-tap-3.patch | text/x-diff | 8.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-03-18 01:20:08 | Re: XID formatting and SLRU refactorings |
Previous Message | Thomas Munro | 2022-03-18 00:50:49 | Re: Declare PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY for aarch64 |