Re: [PATCH] Accept IP addresses in server certificate SANs
От | Jacob Champion |
---|---|
Тема | Re: [PATCH] Accept IP addresses in server certificate SANs |
Дата | |
Msg-id | 6e2bd350e62969a67f35118f3cfbdac36f3a5b51.camel@vmware.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Accept IP addresses in server certificate SANs (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: [PATCH] Accept IP addresses in server certificate SANs
|
Список | 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 по дате отправления: