Re: libpq compression

On Jun15, 2012, at 07:50 , Magnus Hagander wrote:
>>> So I've got very little patience with the idea of "let's put in some
>>> hooks and then great things will happen". It would be far better all
>>> around if we supported exactly one, well-chosen, method. But really
>>> I still don't see a reason not to let openssl do it for us.
>>
>> Do we just need to document SSL's NULL encryption option?
>
> Does the SSL NULL encryption+compression thing work if you're not
> using openssl?

The compression support is defined in RFC 3749, and according to
http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations it's
supported in openssl and gnutls.

gnutls also seems to support a NULL cipher - gnutls-cli on my Ubuntu
10.04 box prints

Ciphers: AES-256-CBC, AES-128-CBC, 3DES-CBC, DES-CBC, ARCFOUR-128,
ARCFOUR-40, RC2-40, CAMELLIA-256-CBC, CAMELLIA-128-CBC, NULL.

> For one thing, some of us still hold a hope to support non-openssl
> libraries in both libpq and server side, so it's something that would
> need to be supported by the standard and thus available in most
> libraries not to invalidate that.

Well, it's a standard a least, and both openssl and gnutls seem to
support it. Are there any other ssl implementations beside gnutls and
openssl that we need to worry about?

> Second, we also have things like the JDBC driver and the .Net driver
> that don't use libpq. the JDBC driver uses the native java ssl
> support, AFAIK. Does that one support the compression, and does it
> support controlling it?

Java uses pluggable providers with standardized interfaces for most
things related to encryption. SSL support is provided by JSSE
(Java Secure Socket Extension). The JSSE implementation included with
the oracle JRE doesn't seem to support compression according to the
wikipedia page quoted above. But chances are that there exists an
alternative implementation which does.

best regards,
Florian Pflug