Date: Wed, 18 Aug 2021 09:32:37 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Jacob Champion <pchampion@vmware.com>
Cc: "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>,
	"andres@anarazel.de" <andres@anarazel.de>,
	"thomas.munro@gmail.com" <thomas.munro@gmail.com>,
	"sfrost@snowman.net" <sfrost@snowman.net>
Subject: Re: Support for NSS as a libpq TLS backend
Message-ID: <YRxVJTPQmX8kWQNf@paquier.xyz>
References: <8335133C-920E-438D-9CEB-DEF4C1533F73@yesql.se>
 <4ec146256e31afa0542f9fa970ec258c5f1a5f98.camel@vmware.com>
 <70A12E33-90B8-4761-8FA6-8DDB9EEA4D3E@yesql.se>
 <14b33300304507db6f4e4d8a77da105a8d18ea1a.camel@vmware.com>
 <FBBFDB5D-644C-45E7-B8F0-016068464B0C@yesql.se>
 <02AB4044-0823-4F77-B69B-18DB378C8743@yesql.se>
 <a0335cb2367c2763ea8da8c79feca80a74c30a07.camel@vmware.com>
 <A89F3823-40BD-4469-AFA8-819C20C0B24D@yesql.se>
 <33A9AFD6-7285-4064-9806-B08D7E61A88C@yesql.se>
 <a1798e46d6d801344ebc93672c6947ef5297c8a0.camel@vmware.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="IiFk7IkVJkH/MeQG"
Content-Disposition: inline
In-Reply-To: <a1798e46d6d801344ebc93672c6947ef5297c8a0.camel@vmware.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YRxVJTPQmX8kWQNf%40paquier.xyz>
Precedence: bulk


--IiFk7IkVJkH/MeQG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Aug 18, 2021 at 12:06:59AM +0000, Jacob Champion wrote:
> I have a local test suite that I've been writing against libpq. With
> the new ssldatabase connection option, one tricky aspect is figuring
> out whether it's supported or not. It doesn't look like there's any way
> to tell, from a client application, whether NSS or OpenSSL (or neither)
> is in use.

That's about guessing which library libpq is compiled with, so yes
that's a problem.

> so that you don't have to have an actual connection first in order to
> figure out what connection options you need to supply. Clients that
> support multiple libpq versions would need to know whether that call is
> reliable (older versions of libpq will always return NULL, whether SSL
> is compiled in or not), so maybe we could add a feature macro at the
> same time?

Still, the problem is wider than that, no?  One cannot know either if
a version of libpq is able to work with GSSAPI until they attempt a
connection with gssencmode.  It seems to me that we should work on the
larger picture here.

> We could also add a new API (say, PQsslLibrary()) but I don't know if
> that gives us anything in practice. Thoughts?

Knowing that the GSSAPI stuff is part of fe-secure.c, we may want
instead a call that returns a list of supported secure libraries.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmEcVSUACgkQnvQgOdby
QH3OwA//aV9yYEJ2gkGbQ5srVM0ryW4XJJJLsCE/9RTHyhl3E12XXvI9hUGQYE7h
jbcVcUtPIdzYFXn49aWi/JACkouPfbI/8kFeYtzRjVNnDoR0sMjgWLTJuh9ivF2Q
S70My+akPPRc0zToN8JC5+mN9Ft667qO4bY4x5FAuVTaTH1GXIcfV9iLF+4DisU5
xW9KFE7KktFSAimubzZaopzUJWFNE/7ojNH7wk08BLpXrdSopC7erInp2aejB1YX
d7TPM54fXyg8rcGk6jRjcxlESu9I4DGXnfegYSb09Z6ql+S0w55akVcYuAdsq2pp
+Zcrnvz0BMDqEx9RYU6ANiEFPBA8OyrNlWaX9QNhHf6hiAf1QtrpKS8EjzK+ADI9
F9PDrOvtLtPRWnmuUbZLS9ljNszoXNoE8/AJQdncv2+lbEw8I+3dwb7+W71uFyxg
dKeGkhacLeSRkTU5KhYhg4LOnlC23KTSaYx4x7RQCZkihgGz7ebdWCDEWfeuxntI
Yf+f1nKhXy/Gn2XkH7GIo8J0kyDMx3OY+Bd8Ljvfns24bENEFUbdfSSPZRrmZpLS
qexVeRCK7XJ48oT28ssMNQW01GE3BaP7AXLFChrfWIpCiKKaTX1GxwyjL0RoVHM1
rU1XSf5JtsugyFpNWf3c/GG07eLbSxfBG2jzixAhOYznEpMS2Mk=
=ppNN
-----END PGP SIGNATURE-----

--IiFk7IkVJkH/MeQG--