pgsql: Set libpq sslcompression to off by default
Set libpq sslcompression to off by default
Since SSL compression is no longer recommended, turn the default in
libpq from on to off.
OpenSSL 1.1.0 and many distribution packages already turn compression
off by default, so such a server won't accept compression anyway. So
this will mainly affect users of older OpenSSL installations.
Also update the documentation to make clear that this setting is no
longer recommended.
Discussion: /messages/by-id/595cf3b1-4ffe-7f05-6f72-f72b7afa7993@2ndquadrant.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/e3bdb2d92600ed45bd46aaf48309a436a9628218
Modified Files
--------------
doc/src/sgml/libpq.sgml | 31 ++++++++++++++++++++-----------
src/interfaces/libpq/fe-connect.c | 2 +-
src/interfaces/libpq/fe-secure-openssl.c | 8 ++++----
3 files changed, 25 insertions(+), 16 deletions(-)
Peter Eisentraut <peter_e@gmx.net> writes:
Set libpq sslcompression to off by default
Buildfarm reports that SSL_clear_options isn't available everywhere.
regards, tom lane
On 17 Mar 2018, at 17:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Set libpq sslcompression to off by default
Buildfarm reports that SSL_clear_options isn't available everywhere.
Per some reading of the documentation and various patchers it seems
SSL_clear_options() was introduced in 0.9.8m and SSL_OP_NO_COMPRESSION in
1.0.0. For older versions, the recommended option is to clear the list of
compression methods in order to disable compression:
#ifndef SSL_OP_NO_COMPRESSION
STACK_OF(SSL_COMP)* comp_methods;
comp_methods = SSL_COMP_get_compression_methods();
sk_SSL_COMP_zero(comp_methods);
#endif
I don’t have an old version handy to try on, so the above is untested.
cheers ./daniel
On 3/17/18 15:12, Daniel Gustafsson wrote:
On 17 Mar 2018, at 17:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Set libpq sslcompression to off by default
Buildfarm reports that SSL_clear_options isn't available everywhere.
Per some reading of the documentation and various patchers it seems
SSL_clear_options() was introduced in 0.9.8m and SSL_OP_NO_COMPRESSION in
1.0.0.
It seems the failure is limited to an old NetBSD version. They might
have patched their libssl locally somehow. Is it worth supporting this?
We could add a configure test for SSL_clear_options().
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 3/17/18 15:12, Daniel Gustafsson wrote:
On 17 Mar 2018, at 17:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Buildfarm reports that SSL_clear_options isn't available everywhere.
Per some reading of the documentation and various patchers it seems
SSL_clear_options() was introduced in 0.9.8m and SSL_OP_NO_COMPRESSION in
1.0.0.
It seems the failure is limited to an old NetBSD version. They might
have patched their libssl locally somehow. Is it worth supporting this?
Dunno, but the other side of the coin is that the goals of this patch
don't seem like a sufficient reason to break backwards compatibility
with any platform.
We could add a configure test for SSL_clear_options().
Kind of annoying, but ...
regards, tom lane
On 20 Mar 2018, at 05:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 3/17/18 15:12, Daniel Gustafsson wrote:
On 17 Mar 2018, at 17:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Buildfarm reports that SSL_clear_options isn't available everywhere.
Per some reading of the documentation and various patchers it seems
SSL_clear_options() was introduced in 0.9.8m and SSL_OP_NO_COMPRESSION in
1.0.0.It seems the failure is limited to an old NetBSD version. They might
have patched their libssl locally somehow. Is it worth supporting this?Dunno, but the other side of the coin is that the goals of this patch
don't seem like a sufficient reason to break backwards compatibility
with any platform.
If we test for SSL_clear_options(), and use the sk_SSL_COMP_zero() where not
available, we should be able to keep backwards compatibility with older OpenSSL
revisions even if the distros have patched them AFAICT. Unless you’re already
working on it I can take a stab at it.
cheers ./daniel
On 3/20/18 04:03, Daniel Gustafsson wrote:
If we test for SSL_clear_options(), and use the sk_SSL_COMP_zero() where not
available, we should be able to keep backwards compatibility with older OpenSSL
revisions even if the distros have patched them AFAICT. Unless you’re already
working on it I can take a stab at it.
I don't think we need to go out of our way to deal with such old
versions (> 8 years AFAICT), especially since we have no way to test it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 20 Mar 2018, at 22:00, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 3/20/18 04:03, Daniel Gustafsson wrote:
If we test for SSL_clear_options(), and use the sk_SSL_COMP_zero() where not
available, we should be able to keep backwards compatibility with older OpenSSL
revisions even if the distros have patched them AFAICT. Unless you’re already
working on it I can take a stab at it.I don't think we need to go out of our way to deal with such old
versions (> 8 years AFAICT), especially since we have no way to test it.
Fair enough, makes sense.
cheers ./daniel