Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id 94E22878-6289-43D5-A674-804F6CB23782@yesql.se
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
Responses Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
Re: Support for NSS as a libpq TLS backend  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
> On 16 Nov 2020, at 21:00, Jacob Champion <pchampion@vmware.com> wrote:
> On Nov 13, 2020, at 4:14 AM, Daniel Gustafsson <daniel@yesql.se> wrote:

>> I've incorporated this patch as well as the previous patch for the assertion
>> failure on private callback data into the attached v19 patchset.  I also did a
>> spellcheck and pgindent run on it for ease of review.
>
> Commit 6be725e70 got rid of some psql error messaging that the tests
> were keying off of, so there are a few new failures after a rebase onto
> latest master.
>
> I've attached a patch that gets the SCRAM tests a little further
> (certificate hashing was caught in an infinite loop). I also added error
> checks to those loops, along the lines of the existing OpenSSL
> implementation: if a suitable digest can't be found, the user will see
> an error like
>
>    psql: error: could not find digest for OID 'PKCS #1 SHA-256 With RSA Encryption'
>
> It's a little verbose but I don't think this case should come up in
> normal practice.

Nice, thanks for the fix!  I've incorporated your patch into the attached v20
which also fixes client side error reporting to be more readable.  The SCRAM
tests are now also hooked up, albeit with SKIP blocks for NSS, so they can
start getting fixed.

cheers ./daniel


Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Is it useful to record whether plans are generic or custom?
Next
From: Victor Yegorov
Date:
Subject: Re: Deleting older versions in unique indexes to avoid page splits