Re: Support for NSS as a libpq TLS backend

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Jacob Champion <pchampion(at)vmware(dot)com>
Cc: "thomas(dot)munro(at)gmail(dot)com" <thomas(dot)munro(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>
Subject: Re: Support for NSS as a libpq TLS backend
Date: 2021-02-17 21:19:35
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 17 Feb 2021, at 02:02, Jacob Champion <pchampion(at)vmware(dot)com> wrote:

> On Mon, 2020-07-20 at 15:35 +0200, Daniel Gustafsson wrote:
>> This version adds support for sslinfo on NSS for most the functions.
> I've poked around to see what can be done about the
> unimplemented ssl_client_dn_field/ssl_issuer_field functions. There's a
> nasty soup of specs to wade around in, and it's not really clear to me
> which ones take precedence since they're mostly centered on LDAP.

Thanks for digging!

> we could hardcode the list of OpenSSL-compatible names, and just
> translate manually in sslinfo. Then leave the rest up to dotted-decimal
> OIDs.
> Would that be desirable, or do we want this interface to be something
> more generally compatible with (some as-of-yet unspecified) spec?

Regardless of approach taken I think this sounds like something that should be
tackled in a follow-up patch if the NSS patch is merged - and probably only as
a follow-up to a patch that adds test coverage to sslinfo. From the sounds of
things me may not be able to guarantee stability across OpenSSL versions as it
is right now?

Daniel Gustafsson

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-02-17 21:35:33 Re: Support for NSS as a libpq TLS backend
Previous Message Tom Lane 2021-02-17 21:00:36 Re: Some regular-expression performance hacking