Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id YBJUaMj1EdpWVCgb@paquier.xyz
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
Responses Re: Support for NSS as a libpq TLS backend  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On Wed, Jan 27, 2021 at 06:47:17PM +0000, Jacob Champion wrote:
> So to check understanding: the `openssl` config variable is still alive
> for MSVC builds; it just turns that into `--with-ssl=openssl` in the
> fake CONFIGURE_ARGS?

Yeah, I think that keeping both variables separated in the MSVC
scripts is the most straight-forward option, as this passes down a
path.  Once there is a value for nss, we'd need to properly issue an
error if both OpenSSL and NSS are specified.

> Since SSL is an obsolete term, and the choice of OpenSSL vs NSS vs
> [nothing] affects server operation (such as cryptohash) regardless of
> whether or not connection-level TLS is actually used, what would you
> all think about naming this option --with-crypto? I.e.
>
>     --with-crypto=openssl
>     --with-crypto=nss

Looking around, curl has multiple switches for each lib with one named
--with-ssl for OpenSSL, but it needs to be able to use multiple
libraries at run time.  I can spot that libssh2 uses what you are
proposing.  It seems to me that --with-ssl is a bit more popular but
not by that much: wget, wayland, some apache stuff (it uses a path as
option value).  Anyway, what you are suggesting sounds like a good in
the context of Postgres.  Daniel?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Next
From: Peter Smith
Date:
Subject: Re: Single transaction in the tablesync worker?