> On 30 Nov 2021, at 20:03, Jacob Champion <pchampion@vmware.com> wrote:
>
> On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
>>> Speaking of IP addresses in SANs, it doesn't look like our OpenSSL
>>> backend can handle those. That's a separate conversation, but I might
>>> take a look at a patch for next commitfest.
>>
>> Please do.
>
> Didn't get around to it for November, but I'm putting the finishing
> touches on that now.
Cool, thanks!
> While I was looking at the new SAN code (in fe-secure-nss.c,
> pgtls_verify_peer_name_matches_certificate_guts()), I noticed that code
> coverage never seemed to touch a good chunk of it:
>
>> + for (cn = san_list; cn != san_list; cn = CERT_GetNextGeneralName(cn))
>> + {
>> + char *alt_name;
>> + int rv;
>> + char tmp[512];
>
> That loop can never execute. But I wonder if all of that extra SAN code
> should be removed anyway? There's this comment above it:
>
>> + /*
>> + * CERT_VerifyCertName will internally perform RFC 2818 SubjectAltName
>> + * verification.
>> + */
>
> and it seems like SAN verification is working in my testing, despite
> the dead loop.
Yeah, that's clearly bogus. I followed the bouncing ball reading NSS code and
from what I can tell the comment is correct. I removed the dead code, only
realizing after the fact that I might cause conflict with your tree doing so,
in that case sorry.
I've attached a v50 which fixes the issues found by Joshua upthread, as well as
rebases on top of all the recent SSL and pgcrypto changes.
--
Daniel Gustafsson https://vmware.com/