Andreas Karlsson <andreas@proxel.se> writes:
> On 09/07/2017 11:34 PM, Tomas Vondra wrote:
>> Well, people won't be able to set the inactive options, just like you
>> can't set ssl=on when you build without OpenSSL support. But perhaps we
>> could simply not include the inactive options into the config file, no?
> Yeah, I have been thinking about how bad it would be to dynamically
> generate the config file. I think I will try this.
I'm not exactly convinced that dynamically inserting some parameters
and not others is a great idea. Remember that people tend to copy
postgresql.conf files forward from one installation to another. Or
they might decide to rebuild the postmaster for an existing installation
with a different SSL library. In any scenario like that, you've not
done them any real favor if the config file they have contains no trace
of the SSL parameters they need.
I think we might be best off just playing it straight and providing
a config file that contains a section along these lines:
# Parameters for OpenSSL. Leave these commented out if not using OpenSSL.
#
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
#ssl_prefer_server_ciphers = on
#ssl_ecdh_curve = 'prime256v1'
#ssl_dh_params_file = ''
#ssl_cert_file = 'server.crt'
#ssl_key_file = 'server.key'
#ssl_ca_file = ''
#ssl_crl_file = ''
#
# Parameters for GnuTLS. Leave these commented out if not using GnuTLS.
#
#gnufoo=...
#gnubar=...
#
# Parameters for macOS TLS. ... you get the idea.
As previously noted, it'd be a good idea to rename the existing
ssl_xxx parameters to openssl_xxx, except maybe ones that we think
will be universal. (But even if we do think that, it might be
simpler in the long run to just have three or four totally independent
sections of the config file, instead of some common and some library-
specific parameters.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers