|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
> 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 https://vmware.com/
|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|