[PATCH] configure-time knob to set default ssl ciphers
Hi hackers,
in Fedora, there's crypto initiative where people try to consolidate ssl
cipher settings for (majority of) Fedora services (PostgreSQL is
included).
PostgreSQL server uses 'HIGH:MEDIUM:+3DES:!aNULL' cipher set by default,
but what Fedora would like to have is 'PROFILE=SYSTEM' (works with
Fedora-patched OpenSSL, so please don't waste your time with checking this
elsewhere). What that really does is:
kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!EXP:!DES:!RC4:!RC2:!IDEA\
:!SEED:!eNULL:!aNULL:!MD5:!SSLv2
.. but that's just for the record (should be subset of upstream default);
more info in RH bug [1]https://bugzilla.redhat.com/show_bug.cgi?id=1348125.
I'd like to propose the attached patch, so we could (without downstream
patching) do
$ ./configure ... --with-openssl-be-ciphers=PROFILE=SYSTEM
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1348125
Thanks for considering!
Pavel
Attachments:
0001-Allow-setting-distribution-specific-cipher-set.patchtext/x-patch; charset=UTF-8; name=0001-Allow-setting-distribution-specific-cipher-set.patchDownload
From dae9b8c0345b65882c221a4062f435cf657fe55a Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@redhat.com>
Date: Wed, 18 Jan 2017 13:34:55 +0100
Subject: [PATCH] Allow setting distribution-specific cipher set
Fedora OpenSSL maintainers invented a way to specify consolidated,
per-system cipher set [1] and it is our packaging policy to comply
(if this is a bit meaningful).
So for such situations ./configure options comes in handy instead
of downstream-patching, per Red Hat bug report [2].
[1] https://fedoraproject.org/wiki/Packaging:CryptoPolicies
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1348125
---
configure | 32 ++++++++++++++++++++++++++++++++
configure.in | 8 ++++++++
src/backend/utils/misc/guc.c | 4 ++++
src/include/pg_config.h.in | 3 +++
4 files changed, 47 insertions(+)
diff --git a/configure b/configure
new file mode 100755
index bb285e4..9e7fa82
*** a/configure
--- b/configure
*************** with_bsd_auth
*** 831,836 ****
--- 831,837 ----
with_ldap
with_bonjour
with_openssl
+ with_openssl_be_ciphers
with_selinux
with_systemd
with_readline
*************** Optional Packages:
*** 1521,1526 ****
--- 1522,1529 ----
--with-ldap build with LDAP support
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
+ --with-openssl-be-ciphers=STRING
+ Replace the default list of server-supported ciphers
--with-selinux build with SELinux support
--with-systemd build with systemd support
--without-readline do not use GNU Readline nor BSD Libedit for editing
*************** fi
*** 5712,5717 ****
--- 5715,5749 ----
$as_echo "$with_openssl" >&6; }
+
+
+
+ # Check whether --with-openssl-be-ciphers was given.
+ if test "${with_openssl_be_ciphers+set}" = set; then :
+ withval=$with_openssl_be_ciphers;
+ case $withval in
+ yes)
+ as_fn_error $? "argument required for --with-openssl-be-ciphers option" "$LINENO" 5
+ ;;
+ no)
+ as_fn_error $? "argument required for --with-openssl-be-ciphers option" "$LINENO" 5
+ ;;
+ *)
+
+ cat >>confdefs.h <<_ACEOF
+ #define PG_DEFAULT_SSL_CIPHERS "$with_openssl_be_ciphers"
+ _ACEOF
+
+ ;;
+ esac
+
+ fi
+
+
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to replace default OpenSSL cypher set" >&5
+ $as_echo_n "checking whether to replace default OpenSSL cypher set... " >&6; }
+
#
# SELinux
#
diff --git a/configure.in b/configure.in
new file mode 100644
index 09a887d..f26f1fa
*** a/configure.in
--- b/configure.in
*************** PGAC_ARG_BOOL(with, openssl, no, [build
*** 712,717 ****
--- 712,725 ----
AC_MSG_RESULT([$with_openssl])
AC_SUBST(with_openssl)
+ PGAC_ARG_REQ(with, openssl-be-ciphers, [STRING],
+ [Replace the default list of server-supported ciphers],
+ [AC_DEFINE_UNQUOTED([PG_DEFAULT_SSL_CIPHERS],
+ ["$with_openssl_be_ciphers"],
+ [Re-define the default for server ssl_ciphers option])])
+
+ AC_MSG_CHECKING([whether to replace default OpenSSL cypher set])
+
#
# SELinux
#
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
new file mode 100644
index 4f1891f..8b4e576
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
*************** static struct config_string ConfigureNam
*** 3508,3514 ****
--- 3508,3518 ----
},
&SSLCipherSuites,
#ifdef USE_SSL
+ #ifdef PG_DEFAULT_SSL_CIPHERS
+ PG_DEFAULT_SSL_CIPHERS,
+ #else
"HIGH:MEDIUM:+3DES:!aNULL",
+ #endif
#else
"none",
#endif
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
new file mode 100644
index 7dbfa90..8367744
*** a/src/include/pg_config.h.in
--- b/src/include/pg_config.h.in
***************
*** 738,743 ****
--- 738,746 ----
/* Define to the version of this package. */
#undef PACKAGE_VERSION
+ /* Re-define the default for server ssl_ciphers option */
+ #undef PG_DEFAULT_SSL_CIPHERS
+
/* Define to the name of a signed 128-bit integer type. */
#undef PG_INT128_TYPE
--
2.9.3
Pavel Raiskup <praiskup@redhat.com> writes:
PostgreSQL server uses 'HIGH:MEDIUM:+3DES:!aNULL' cipher set by default,
but what Fedora would like to have is 'PROFILE=SYSTEM' (works with
Fedora-patched OpenSSL, so please don't waste your time with checking this
elsewhere).
...
I'd like to propose the attached patch, so we could (without downstream
patching) do
$ ./configure ... --with-openssl-be-ciphers=PROFILE=SYSTEM
Meh. This is pretty far from a complete patch: it introduces an
undocumented configure switch, and it changes the default value for a GUC
without fixing either the corresponding SGML documentation or the
postgresql.conf.sample line for it.
While it would surely be possible to build all the infrastructure to make
that work right, I'm not really sure that we want to carry around that
much baggage for a single-system hack.
A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.
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
On 2/7/17 11:21 AM, Tom Lane wrote:
A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.
You'd still need to patch postgresql.conf.sample somehow.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 2/7/17 11:21 AM, Tom Lane wrote:
A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.
You'd still need to patch postgresql.conf.sample somehow.
Right. The compromise position that I had in mind was to add the
#define in pg_config_manual.h and teach initdb to propagate it into
the installed copy of postgresql.conf, as we've done with other GUCs
with platform-dependent defaults, such as backend_flush_after.
That still leaves the question of what to do with the SGML docs.
We could add some weasel wording to the effect that the default might
be platform-specific, or we could leave the docs alone and expect the
envisioned Red Hat patch to patch config.sgml along with
pg_config_manual.h.
It looks like the xxx_flush_after GUCs aren't exactly fully documented
as to this point, so we have some work to do there too :-(
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
On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 2/7/17 11:21 AM, Tom Lane wrote:
A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.You'd still need to patch postgresql.conf.sample somehow.
Right. The compromise position that I had in mind was to add the
#define in pg_config_manual.h and teach initdb to propagate it into
the installed copy of postgresql.conf, as we've done with other GUCs
with platform-dependent defaults, such as backend_flush_after.That still leaves the question of what to do with the SGML docs.
We could add some weasel wording to the effect that the default might
be platform-specific, or we could leave the docs alone and expect the
envisioned Red Hat patch to patch config.sgml along with
pg_config_manual.h.
Thanks for quickt feedback. Just to not give up too early, I'm attaching
2nd iteration. I'm fine to fallback to pg_config_manual.h solution though,
if this is considered too bad.
I tried to fix the docs now (crucial part indeed) so we are not that
"scrict" and there's some space for per-distributor change of ssl_ciphers
default.
From the previous mail:
I'm not really sure that we want to carry around that much baggage for a
single-system hack.
Accepted, but still I'm giving a chance. OpenSSL maintainers predict this (or
something else in similar fashion) is going to be invented in OpenSSL upstream.
So there's still some potential in ./configure option.
Thanks!
Pavel
It looks like the xxx_flush_after GUCs aren't exactly fully documented
as to this point, so we have some work to do there too :-(
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
On Wednesday, February 8, 2017 1:29:19 PM CET Pavel Raiskup wrote:
On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 2/7/17 11:21 AM, Tom Lane wrote:
A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.You'd still need to patch postgresql.conf.sample somehow.
Right. The compromise position that I had in mind was to add the
#define in pg_config_manual.h and teach initdb to propagate it into
the installed copy of postgresql.conf, as we've done with other GUCs
with platform-dependent defaults, such as backend_flush_after.That still leaves the question of what to do with the SGML docs.
We could add some weasel wording to the effect that the default might
be platform-specific, or we could leave the docs alone and expect the
envisioned Red Hat patch to patch config.sgml along with
pg_config_manual.h.Thanks for quickt feedback. Just to not give up too early, I'm attaching
2nd iteration. I'm fine to fallback to pg_config_manual.h solution though,
if this is considered too bad.I tried to fix the docs now (crucial part indeed) so we are not that
"scrict" and there's some space for per-distributor change of ssl_ciphers
default.From the previous mail:
I'm not really sure that we want to carry around that much baggage for a
single-system hack.Accepted, but still I'm giving a chance. OpenSSL maintainers predict this (or
something else in similar fashion) is going to be invented in OpenSSL upstream.
So there's still some potential in ./configure option.
Argh :( ! Attaching now and sorry.
Pavel
Show quoted text
Thanks!
PavelIt looks like the xxx_flush_after GUCs aren't exactly fully documented
as to this point, so we have some work to do there too :-(regards, tom lane
Attachments:
0001-Allow-setting-distribution-specific-cipher-set.patchtext/x-patch; charset=UTF-8; name=0001-Allow-setting-distribution-specific-cipher-set.patchDownload
From 41f73a910bb7afc2afa12be35a195df317f9447b Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <praiskup@redhat.com>
Date: Wed, 18 Jan 2017 13:34:55 +0100
Subject: [PATCH] Allow setting distribution-specific cipher set
Fedora OpenSSL maintainers invented a way to specify consolidated,
per-system cipher set [1] and it is our packaging policy to comply
(if this is a bit meaningful).
So for such situations ./configure options comes in handy instead
of downstream-patching, per Red Hat bug report [2].
[1] https://fedoraproject.org/wiki/Packaging:CryptoPolicies
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1348125
---
configure | 34 +++++++++++++++++++++++++++
configure.in | 10 ++++++++
doc/src/sgml/config.sgml | 3 ++-
doc/src/sgml/installation.sgml | 15 ++++++++++++
src/backend/utils/misc/guc.c | 2 +-
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/bin/initdb/initdb.c | 4 ++++
src/include/pg_config.h.in | 3 +++
8 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
new file mode 100755
index bb285e4..15fad9e
*** a/configure
--- b/configure
*************** with_bsd_auth
*** 831,836 ****
--- 831,837 ----
with_ldap
with_bonjour
with_openssl
+ with_openssl_be_ciphers
with_selinux
with_systemd
with_readline
*************** Optional Packages:
*** 1521,1526 ****
--- 1522,1529 ----
--with-ldap build with LDAP support
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
+ --with-openssl-be-ciphers=STRING
+ Replace the default list of server-supported ciphers
--with-selinux build with SELinux support
--with-systemd build with systemd support
--without-readline do not use GNU Readline nor BSD Libedit for editing
*************** fi
*** 5712,5717 ****
--- 5715,5751 ----
$as_echo "$with_openssl" >&6; }
+ pg_be_ciphers=HIGH:MEDIUM:+3DES:!aNULL
+
+
+
+ # Check whether --with-openssl-be-ciphers was given.
+ if test "${with_openssl_be_ciphers+set}" = set; then :
+ withval=$with_openssl_be_ciphers;
+ case $withval in
+ yes)
+ as_fn_error $? "argument required for --with-openssl-be-ciphers option" "$LINENO" 5
+ ;;
+ no)
+ as_fn_error $? "argument required for --with-openssl-be-ciphers option" "$LINENO" 5
+ ;;
+ *)
+ pg_be_ciphers=$withval
+ ;;
+ esac
+
+ fi
+
+
+
+ cat >>confdefs.h <<_ACEOF
+ #define PG_DEFAULT_SSL_CIPHERS "$pg_be_ciphers"
+ _ACEOF
+
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to replace default OpenSSL cypher set" >&5
+ $as_echo_n "checking whether to replace default OpenSSL cypher set... " >&6; }
+
#
# SELinux
#
diff --git a/configure.in b/configure.in
new file mode 100644
index 09a887d..fc5c3a1
*** a/configure.in
--- b/configure.in
*************** PGAC_ARG_BOOL(with, openssl, no, [build
*** 712,717 ****
--- 712,727 ----
AC_MSG_RESULT([$with_openssl])
AC_SUBST(with_openssl)
+ pg_be_ciphers=HIGH:MEDIUM:+3DES:!aNULL
+ PGAC_ARG_REQ(with, openssl-be-ciphers, [STRING],
+ [Replace the default list of server-supported ciphers],
+ [pg_be_ciphers=$withval])
+ AC_DEFINE_UNQUOTED([PG_DEFAULT_SSL_CIPHERS],
+ ["$pg_be_ciphers"],
+ [Define the default for server ssl_ciphers option])
+
+ AC_MSG_CHECKING([whether to replace default OpenSSL cypher set])
+
#
# SELinux
#
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index 7c56a57..83f11cf
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*************** include_dir 'conf.d'
*** 1046,1052 ****
used on secure connections. See
the <citerefentry><refentrytitle>ciphers</></citerefentry> manual page
in the <application>OpenSSL</> package for the syntax of this setting
! and a list of supported values. The default value is
<literal>HIGH:MEDIUM:+3DES:!aNULL</>. It is usually reasonable,
unless you have specific security requirements. This parameter can only
be set at server start.
--- 1046,1053 ----
used on secure connections. See
the <citerefentry><refentrytitle>ciphers</></citerefentry> manual page
in the <application>OpenSSL</> package for the syntax of this setting
! and a list of supported values. The default value is normally
! (configurable, see <xref linkend="configure-ssl-ciphers">)
<literal>HIGH:MEDIUM:+3DES:!aNULL</>. It is usually reasonable,
unless you have specific security requirements. This parameter can only
be set at server start.
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
new file mode 100644
index 25a4943..dfd8336
*** a/doc/src/sgml/installation.sgml
--- b/doc/src/sgml/installation.sgml
*************** su - postgres
*** 1157,1162 ****
--- 1157,1177 ----
</listitem>
</varlistentry>
+ <varlistentry id="configure-ssl-ciphers" xreflabel="configure-ssl-ciphers">
+ <term><option>--with-openssl-be-ciphers</option></term>
+ <listitem>
+ <para>
+ <indexterm>
+ <primary>default backend SSL ciphers</primary>
+ </indexterm>
+ Configures the default value of 'ssl_ciphers' option set by
+ <command>initdb</>.
+ <![%standalone-ignore[See <xref linkend="guc-ssl-ciphers">
+ for more information.]]>
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><option>--enable-debug</option></term>
<listitem>
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
new file mode 100644
index 4f1891f..a8a73b0
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
*************** static struct config_string ConfigureNam
*** 3508,3514 ****
},
&SSLCipherSuites,
#ifdef USE_SSL
! "HIGH:MEDIUM:+3DES:!aNULL",
#else
"none",
#endif
--- 3508,3514 ----
},
&SSLCipherSuites,
#ifdef USE_SSL
! PG_DEFAULT_SSL_CIPHERS,
#else
"none",
#endif
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
new file mode 100644
index fa6c0ea..ff2b181
*** a/src/backend/utils/misc/postgresql.conf.sample
--- b/src/backend/utils/misc/postgresql.conf.sample
***************
*** 77,83 ****
#authentication_timeout = 1min # 1s-600s
#ssl = off # (change requires restart)
! #ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
# (change requires restart)
#ssl_prefer_server_ciphers = on # (change requires restart)
#ssl_ecdh_curve = 'prime256v1' # (change requires restart)
--- 77,83 ----
#authentication_timeout = 1min # 1s-600s
#ssl = off # (change requires restart)
! #ssl_ciphers = '' # allowed SSL ciphers
# (change requires restart)
#ssl_prefer_server_ciphers = on # (change requires restart)
#ssl_ecdh_curve = 'prime256v1' # (change requires restart)
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
new file mode 100644
index 27d134e..311c130
*** a/src/bin/initdb/initdb.c
--- b/src/bin/initdb/initdb.c
*************** setup_config(void)
*** 1308,1313 ****
--- 1308,1317 ----
repltok);
#endif
+ snprintf(repltok, sizeof(repltok),
+ "#ssl_ciphers = '" PG_DEFAULT_SSL_CIPHERS "'"),
+ conflines = replace_token(conflines, "#ssl_ciphers = ''", repltok);
+
#ifndef USE_PREFETCH
conflines = replace_token(conflines,
"#effective_io_concurrency = 1",
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
new file mode 100644
index 7dbfa90..8190879
*** a/src/include/pg_config.h.in
--- b/src/include/pg_config.h.in
***************
*** 738,743 ****
--- 738,746 ----
/* Define to the version of this package. */
#undef PACKAGE_VERSION
+ /* Define the default for server ssl_ciphers option */
+ #undef PG_DEFAULT_SSL_CIPHERS
+
/* Define to the name of a signed 128-bit integer type. */
#undef PG_INT128_TYPE
--
2.9.3
On 08 Feb 2017, at 13:31, Pavel Raiskup <praiskup@redhat.com> wrote:
On Wednesday, February 8, 2017 1:29:19 PM CET Pavel Raiskup wrote:
On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 2/7/17 11:21 AM, Tom Lane wrote:
A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.You'd still need to patch postgresql.conf.sample somehow.
Right. The compromise position that I had in mind was to add the
#define in pg_config_manual.h and teach initdb to propagate it into
the installed copy of postgresql.conf, as we've done with other GUCs
with platform-dependent defaults, such as backend_flush_after.That still leaves the question of what to do with the SGML docs.
We could add some weasel wording to the effect that the default might
be platform-specific, or we could leave the docs alone and expect the
envisioned Red Hat patch to patch config.sgml along with
pg_config_manual.h.Thanks for quickt feedback. Just to not give up too early, I'm attaching
2nd iteration. I'm fine to fallback to pg_config_manual.h solution though,
if this is considered too bad.I tried to fix the docs now (crucial part indeed) so we are not that
"scrict" and there's some space for per-distributor change of ssl_ciphers
default.From the previous mail:
I'm not really sure that we want to carry around that much baggage for a
single-system hack.Accepted, but still I'm giving a chance. OpenSSL maintainers predict this (or
something else in similar fashion) is going to be invented in OpenSSL upstream.
So there's still some potential in ./configure option.Argh :( ! Attaching now and sorry.
Since we hopefully will support more SSL libraries than OpenSSL at some point,
and we don’t want a torrent of configure options, wouldn’t this be better as
--with-server-ciphers=STRING or something similar?
+ --with-openssl-be-ciphers=STRING
+ Replace the default list of server-supported ciphersEach SSL implementation would then be responsible for handling it appropriately.
cheers ./daniel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
Since we hopefully will support more SSL libraries than OpenSSL at some point,
and we don’t want a torrent of configure options, wouldn’t this be better as
--with-server-ciphers=STRING or something similar?
One of the reasons I'm not very excited about exposing this as a configure
option is exactly that I'm not sure what happens when we get multiple TLS
library support. The cipher list we've got at the moment seems like it
is probably OpenSSL-specific (but maybe not?). If we did have code for
multiple libraries, perhaps some people would want to compile all the
variants at once; in which case overloading a single option to be used for
all the libraries would be a problem.
This would all be a lot clearer if we already had that code, but since
we don't, I'm inclined to be conservative about exposing new features
that make assumptions about how it will be.
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
Tom Lane wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
Since we hopefully will support more SSL libraries than OpenSSL at some point,
and we don’t want a torrent of configure options, wouldn’t this be better as
--with-server-ciphers=STRING or something similar?One of the reasons I'm not very excited about exposing this as a configure
option is exactly that I'm not sure what happens when we get multiple TLS
library support. The cipher list we've got at the moment seems like it
is probably OpenSSL-specific (but maybe not?).
Maybe the list of ciphers is not OpenSSL-specific, but the *syntax* most
likely is. Particularly the abbreviations such as !eNULL and !MD5, etc.
If we did have code for multiple libraries, perhaps some people would
want to compile all the variants at once; in which case overloading a
single option to be used for all the libraries would be a problem.
Hmm, I don't think our abstraction would allow for compiling more than
one at a time. ISTM that all that work has been considering that you'd
choose at most one at compile time. I'm not sure it's useful to have
more than one anyway. If you choose one SSL implementation at configure
time, it's on your head to specify a ssl-ciphers that that
implementation accepts (of course, we would choose a working default if
you don't specify one.)
(I was going to suggest --with-ssl-ciphers but the protocol is called
TLS nowadays, so maybe not a great idea.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Tom Lane wrote:
If we did have code for multiple libraries, perhaps some people would
want to compile all the variants at once; in which case overloading a
single option to be used for all the libraries would be a problem.
Hmm, I don't think our abstraction would allow for compiling more than
one at a time. ISTM that all that work has been considering that you'd
choose at most one at compile time.
Very possibly it'll end up that way. But I'm not eager to pre-judge that
decision, especially if we're doing it only to support a system-specific
hack that could be handled in other ways.
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