Re: Support for NSS as a libpq TLS backend

> On 20 Jan 2021, at 18:07, Jacob Champion <pchampion(at)vmware(dot)com> wrote:

> To continue the Subject Common Name discussion [1] from a different
> part of the thread:
>
> Attached is a v23 version of the patchset that peels the raw Common
> Name out from a client cert's Subject. This allows the following cases
> that the OpenSSL implementation currently handles:
>
> - subjects that don't begin with a CN
> - subjects with quotable characters
> - subjects that have no CN at all

Nice, thanks for fixing this!

> Embedded NULLs are now handled in a similar manner to the OpenSSL side,
> though because this failure happens during the certificate
> authentication callback, it results in a TLS alert rather than simply
> closing the connection.

But returning SECFailure from the cert callback force NSS to terminate the
connection immediately doesn't it?

> For easier review of just the parts I've changed, I've also attached a
> since-v22.diff, which is part of the 0001 patch.

I confused my dev trees and missed to include this in the v23 that I sent out
(which should've been v24), sorry about that. Attached is a v24 which is
rebased on top of todays --with-ssl commit, and now includes your changes.

Additionally I've added a shutdown callback such that we close the connection
immediately if NSS is shutting down from underneath us. I can't imagine a
scenario in which that's benign, so let's take whatever precautions we can.

I've also changed the NSS initialization in the cryptohash code to closer match
what the NSS documentation recommends for similar scenarios, but more on that
downthread where that's discussed.

--
Daniel Gustafsson https://vmware.com/