Обсуждение: 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: https://www.postgresql.org/message-id/flat/595cf3b1-4ffe-7f05-6f72-f72b7afa7993%402ndquadrant.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