Horton

Re: Support for NSS as a libpq TLS backend

Jacob Champion <pchampion@vmware.com>

View thread View on postgr.es
From: Jacob Champion <pchampion@vmware.com>
To: "daniel@yesql.se" <daniel@yesql.se>, "sfrost@snowman.net" <sfrost@snowman.net>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "hlinnaka@iki.fi" <hlinnaka@iki.fi>, "andrew.dunstan@2ndquadrant.com" <andrew.dunstan@2ndquadrant.com>, "thomas.munro@gmail.com" <thomas.munro@gmail.com>, "michael@paquier.xyz" <michael@paquier.xyz>, "andres@anarazel.de" <andres@anarazel.de>
Date: 2021-03-25T23:59:16Z
Lists: pgsql-hackers 
On Fri, 2021-03-26 at 00:22 +0100, Daniel Gustafsson wrote:
> > On 23 Mar 2021, at 20:04, Stephen Frost <sfrost@snowman.net> wrote:
> > 
> > Eh, poor wording on my part.  You're right, the question, reworded
> > again, was "Would someone want to get the context returned by
> > NSS_InitContext?".  If we think there's a reason that someone might want
> > that context then perhaps we should allow getting it, in addition to the
> > pr_fd.  If there's really no reason to ever want the context from
> > NSS_InitContext then what you have here where we're returning pr_fd is
> > probably fine.
> 
> I can't think of any reason, maybe Jacob who has been knee-deep in NSS contexts
> have insights which tell a different story?

The only thing you can do with a context pointer is shut it down, and I
don't think that's something that should be exposed.

--Jacob

Commits

  1. Add tab-completion for CREATE FOREIGN TABLE.

  2. Add tap tests for the schema publications.

  3. Move Perl test modules to a better namespace

  4. Adjust configure to insist on Perl version >= 5.8.3.

  5. Simplify code related to compilation of SSL and OpenSSL

  6. Introduce --with-ssl={openssl} as a configure option

  7. Implement support for bulk inserts in postgres_fdw

  8. Fix redundant error messages in client tools

  9. doc: Apply more consistently <productname> markup for OpenSSL

  10. Check ssl_in_use flag when reporting statistics