Date: Wed, 24 Mar 2021 09:28:10 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Jacob Champion <pchampion@vmware.com>
Cc: "daniel@yesql.se" <daniel@yesql.se>,
	"sfrost@snowman.net" <sfrost@snowman.net>,
	"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: <YFqHmspKASMHcH7V@paquier.xyz>
References: <DDC8E390-1044-4693-AE34-81731B2291FA@yesql.se>
 <0F5CF84D-26F1-44D0-AEAE-E011D3CEC0E2@yesql.se>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Pw0ELNWenYb+6S32"
Content-Disposition: inline
In-Reply-To: <743a11e6668bef648c7a53f862038e6b2fad3755.camel@vmware.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YFqHmspKASMHcH7V%40paquier.xyz>
Precedence: bulk


--Pw0ELNWenYb+6S32
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Mar 24, 2021 at 12:05:35AM +0000, Jacob Champion wrote:
> The first database loaded by NSS_InitContext() becomes the "default"
> database. This is what I'm currently hung up on. I can't figure out how
> to get NSS to use the database that was loaded for the current
> connection, so in my local patches for the issues above, client
> certificates fail to load. I can work around it temporarily for the
> tests, but this will be a problem if any libpq clients load up multiple
> independent databases for use with separate connections. Anyone know if
> this is a supported use case for NSS?

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.
--
Michael

--Pw0ELNWenYb+6S32
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmBah5oACgkQnvQgOdby
QH0l+A//VdbcmeKXCYssiwzcFk6OMz57CvNgXrG6CA1BQ96bCAOAFXmMJqRsrCnn
9nhY9npYLkLMResjtoMX0oA9L7BTXU0zQu2F8O77TE/PHUEAXuILU6KUMeYSyK1F
VQD3yxZMAdCAwcquINqMYrs8V93TMZh3pvta7PxETn8IGsvSA3shPsUebfYyfBK8
/SwhQkP/HxAFFvENBe4Qwhw4peWi4KS0zQEB4XFnDtTJUhAtgDWP7AJrsCFls8AG
9oFbPJWo+ZAQtlYS2OtKBxtXbMCT1TT8iIqnGTmY5t5QMkFh74X+QOFEdLGN4iCo
GN90EC/zTORrlEZDv3Zv5PXx6Xcv65upZlqaw8VxCpHnCg74o5F9E1o4CC02nhTO
9DCFIg+JL48ptjWjpzg2iHOWS1GNiA9/RYFqQGB7MCTIMvOAORldWMoqtegOpfZY
Q7l635oSx7FFAbYsU1uWIQ/AUvz801Hxkpl0mbjMuc5GvUD7vrr08X/4X9vuX5AI
nBK295KN3zSwBTwMMS29gyq0LaXijAJzgWvApwDltSSnHoZryuu5arBj4rr87Wy1
qiEBq0inFdrSAQuVCBak+98//kcgi0O9Wo692bhhtTW2jyZRjlO+XEGd6aIv1bLx
kkunxTlISaJurm7Gm7NmO6b1XRY0Zqd+B3J82D9qArrQYJ/ouq0=
=aNRy
-----END PGP SIGNATURE-----

--Pw0ELNWenYb+6S32--