Date: Wed, 24 Mar 2021 13:00:36 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Jacob Champion <pchampion@vmware.com>
Cc: "michael@paquier.xyz" <michael@paquier.xyz>,
	"daniel@yesql.se" <daniel@yesql.se>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
	"hlinnaka@iki.fi" <hlinnaka@iki.fi>,
	"andrew.dunstan@2ndquadrant.com" <andrew.dunstan@2ndquadrant.com>,
	"thomas.munro@gmail.com" <thomas.munro@gmail.com>,
	"andres@anarazel.de" <andres@anarazel.de>
Subject: Re: Support for NSS as a libpq TLS backend
Message-ID: <20210324170036.GS20766@tamriel.snowman.net>
References: <686dd2b189ec04b161f71481f1f726255ee8224f.camel@vmware.com>
 <AB4CA717-2B6E-4782-AD7D-4FD99CCB6338@yesql.se>
 <1b16041447d57b45ca273f41d26f6e298d756f99.camel@vmware.com>
 <04E81B50-ACE9-40D3-9C66-7041F969A958@yesql.se>
 <21FABD55-5F80-4D8B-B994-3DB81D8742EE@yesql.se>
 <20210321234950.GQ20766@tamriel.snowman.net>
 <F25D6A6A-8FCB-4188-B6E5-5587BABE4D3E@yesql.se>
 <743a11e6668bef648c7a53f862038e6b2fad3755.camel@vmware.com>
 <YFqHmspKASMHcH7V@paquier.xyz>
 <05da9d530ab01e6959bd50c993d590ad73575c21.camel@vmware.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="/P4RV2zBjqDhjw4x"
Content-Disposition: inline
In-Reply-To: <05da9d530ab01e6959bd50c993d590ad73575c21.camel@vmware.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20210324170036.GS20766%40tamriel.snowman.net>
Precedence: bulk


--/P4RV2zBjqDhjw4x
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings Jacob,

* Jacob Champion (pchampion@vmware.com) wrote:
> On Wed, 2021-03-24 at 09:28 +0900, Michael Paquier wrote:
> > On Wed, Mar 24, 2021 at 12:05:35AM +0000, Jacob Champion wrote:
> > > I can work around it temporarily for the
> > > tests, but this will be a problem if any libpq clients load up multip=
le
> > > independent databases for use with separate connections. Anyone know =
if
> > > this is a supported use case for NSS?
> >=20
> > Are you referring to the case of threading here?  This should be a
> > supported case, as threads created by an application through libpq
> > could perfectly use completely different connection strings.
> Right, but to clarify -- I was asking if *NSS* supports loading and
> using separate certificate databases as part of its API. It seems like
> the internals make it possible, but I don't see the public interfaces
> to actually use those internals.

Yes, this is done using SECMOD_OpenUserDB, see:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11_Functi=
ons#SECMOD_OpenUserDB

also there's info here:

https://groups.google.com/g/mozilla.dev.tech.crypto/c/Xz6Emfcue0E

We should document that, as mentioned in the link above, the NSS find
functions will find certs in all the opened databases.  As this would
all be under one application which is linked against libpq and passing
in different values for ssl_database for different connections, this
doesn't seem like it's really that much of an issue.

Thanks!

Stephen

--/P4RV2zBjqDhjw4x
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJgW3A0AAoJEO1sijiDR2RVPBAQAL+m4u8UFuabOVjh6OF/jTR7
1daFKI1XXxti9srZISnYBUlWUFHzbE49lu56KZQhBJpIbp2nPvwVvBBR+92kxWYe
Tj9XUJzgc8H1n2Jo4lKuX2IekBXvm2tb1B3pabvLv3leRV4ejbJJn5V6nEZAPAUE
8h3soES9lbw+kPH2NmO1UxD5oSpXzTV6+x5xAyiZDFUp0k6YHJkBOxKuWhmedMmD
urSKfdCEk2f56AdNCCCSdry3vzkoPVzgaMZTqOzymlE9qk+iqRLrY6RqEKlkFpZt
FBALXumcbB63dB3F6kE0cAYxdKqnNQYr2FarXsOnnPucwKAjh/LJ2k1UJ+41+cvy
EJBgJHCbgwlLJm4S0lKvIWSl3ExXzI6W1HaUK2T01j7eNvCURTJCayIGfhB1gUXs
S8EIFIFAY/Ika04YznTIC8c7NxjNZH62OXpvLOmSdh6ELp7b2+P7iC7GaHMxb8Ap
Y85jI/UxQAiX6cViGslfoUCuvaxjUQ5SRciGbl3XZJTVF+KTN0vBlUFl0Sh3IlQF
nv4tNrDze2G4Z4DeuYn3ymGBNxEkKOIBDNkS17TXMpT7Y5UsT4g9zZEL0PzUvIa9
wUW3dDHQEley80vnbC2XU+7DTF5ocvnzT2zMs46DEGayfWkhr28Nk0jXX/V1eNSz
5BsZIuwspFAsNYvXAP1y
=SnyV
-----END PGP SIGNATURE-----

--/P4RV2zBjqDhjw4x--