Re: Support for NSS as a libpq TLS backend
От | Jacob Champion |
---|---|
Тема | Re: Support for NSS as a libpq TLS backend |
Дата | |
Msg-id | f8cf1c75cb694744ab6ef5c9a7eb2b53b4c5a540.camel@vmware.com обсуждение исходный текст |
Ответ на | Re: Support for NSS as a libpq TLS backend (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: Support for NSS as a libpq TLS backend
|
Список | pgsql-hackers |
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. 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. --Jacob
В списке pgsql-hackers по дате отправления: