Re: [PATCH] Accept IP addresses in server certificate SANs - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [PATCH] Accept IP addresses in server certificate SANs
Date
Msg-id 6e2bd350e62969a67f35118f3cfbdac36f3a5b51.camel@vmware.com
Whole thread Raw
In response to Re: [PATCH] Accept IP addresses in server certificate SANs  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: [PATCH] Accept IP addresses in server certificate SANs
List pgsql-hackers
On Wed, 2022-03-16 at 15:56 +0900, Kyotaro Horiguchi wrote:
> At Tue, 15 Mar 2022 21:41:49 +0000, Jacob Champion <pchampion@vmware.com> wrote in 
> > Hmm, the sslinfo tests are failing? I wouldn't have expected that based
> > on the patch changes. Just to confirm -- they pass for you without the
> > patch?
> 
> Mmm.... I'm not sure how come I didn't noticed that, master also fails
> for me fo the same reason.  In the past that may fail when valid
> clinent-certs exists in the users ~/.postgresql but I believe that has
> been fixed.

Good to know; I was worried that I'd messed up something well outside
the code I'd touched.

> > > > > Mmm. after the end of the loop, rc is non-zero only when the loop has
> > > > > exited by the break and otherwise rc is zero. Why isn't it equivalent
> > > > > to setting check_cn to false at the break?
> > > > 
> > > > check_cn can be false if rc is zero, too; it means that we found a SAN
> > > > of the correct type but it didn't match.
> 
> I'm not discussing on the meaning. Purely on the logical equivalancy
> of the two ways to decide whether to visit CN.
> 
> Concretely, the equivalancy between this: [snip]

Thank you for the explanation -- the misunderstanding was all on my
end. I thought you were asking me to move the check_cn assignment
instead of copying it to the end. I agree that your suggestion is much
clearer, and I'll make that change tomorrow.

Thanks!
--Jacob

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum
Next
From: Japin Li
Date:
Subject: Re: Support logical replication of DDLs