public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jacob Champion <[email protected]>
To: [email protected] <[email protected]>
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Support for NSS as a libpq TLS backend
Date: Fri, 29 Jan 2021 18:46:17 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<YAUz/[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Fri, 2021-01-29 at 13:57 +0100, Daniel Gustafsson wrote:
> > On 21 Jan 2021, at 06:21, Michael Paquier <[email protected]> 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

view thread (181+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Support for NSS as a libpq TLS backend
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox