| 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 |
| Message-ID: | 06EFBB38-C0D2-440F-95CB-9B3AE4F97E82@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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 https://vmware.com/
| 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 |