From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "daniel(at)yesql(dot)se" <daniel(at)yesql(dot)se>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz> |
Cc: | "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "andrew(dot)dunstan(at)2ndquadrant(dot)com" <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "thomas(dot)munro(at)gmail(dot)com" <thomas(dot)munro(at)gmail(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net> |
Subject: | Re: Support for NSS as a libpq TLS backend |
Date: | 2021-01-29 18:46:17 |
Message-ID: | 40095f48c3c6d556293cb0ecf80ea10cdf7d26b3.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2021-01-29 at 13:57 +0100, Daniel Gustafsson wrote:
> > On 21 Jan 2021, at 06:21, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > I really need to study more the choide of the options chosen for
> > NSS_InitContext()... But based on the docs I can read on the matter I
> > think that saving nsscontext in pg_cryptohash_ctx is right for each
> > cryptohash built.
>
> It's a safe but slow option, NSS wasn't really made for running a single crypto
> operation. Since we are opening a context which isn't backed by an NSS
> database we could have a static context, which indeed speeds up processing a
> lot. The problem with that is that there is no good callsite for closing the
> context as the backend is closing down. Since you are kneedeep in the
> cryptohash code, do you have any thoughts on this? I've included 0008 which
> implements this, with a commented out dummy stub for cleaning up.
>
> Making nss_context static in cryptohash_nss.c is
> appealing but there is no good option for closing it there. Any thoughts on
> how to handle global contexts like this?
I'm completely new to this code, so take my thoughts with a grain of
salt...
I think the bad news is that the static approach will need support for
ENABLE_THREAD_SAFETY. (It looks like the NSS implementation of
pgtls_close() needs some thread support too?)
The good(?) news is that I don't understand why OpenSSL's
implementation of cryptohash doesn't _also_ need the thread-safety
code. (Shouldn't we need to call CRYPTO_set_locking_callback() et al
before using any of its cryptohash implementation?) So maybe we can
implement the same global setup/teardown API for OpenSSL too and not
have to one-off it for NSS...
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Martinez | 2021-01-29 18:53:28 | Re: [PATCH] pg_hba.conf error messages for logical replication connections |
Previous Message | Fujii Masao | 2021-01-29 18:44:30 | Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit |