Re: [PATCH] Accept IP addresses in server certificate SANs
Jacob Champion <pchampion@vmware.com>
From: Jacob Champion <pchampion@vmware.com>
To: "horikyota.ntt@gmail.com" <horikyota.ntt@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-03-16T23:49:48Z
Lists: 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
Commits
-
libpq: Allow IP address SANs in server certificates
- c1932e542863 15.0 landed
-
Add SSL tests for IP addresses in certificates
- af9e18049550 15.0 landed
-
Make JSON path numeric literals more correct
- e26114c817b6 15.0 cited