On Wednesday, November 9, 2011, Albe Laurenz wrote:
Christopher Browne wrote:
>> I think that JDBC and Npgsql should also support disabling
compression.
>
> That's the *real* problem here...
>
> You're quite right that if we allow controlling this on the libpq
> side, it is surely desirable to allow controlling this via JDBC,
> Npgsql, and other mechanisms people may have around.
[...]
> With that series of complications, I wonder if maybe the right place
> to control this is pg_hba.conf.
I think that wouldn't work, because to query pg_hba.conf, you have to
know user and database, which come from the client side.
But the SSL negotiation takes place earlier, namely when the
connection is established.
Oh, right, that's going to be a problem doing it there.
> I wonder how many SSL parameters there are which would be worth trying
> to have available. I expect we'd benefit from looking at all the
> relevant ones at once, so as to not have the problem of hacking "one
> more" into place and perhaps doing it a bit differently each time.
Sure, if anybody can think of any. A quick look at
"man SSL_CTX_set_options" didn't show me any, but then OpenSSL's
documentation is very bad (the page does not even mention
SSL_OP_NO_COMPRESSION) and I am no SSL expert.
Oh yeah, their docs are. Um. Yeah, let's leave it at that.
I think the other one is to control which encryption options are available - but we already have a guc for that.
Is the following proposal acceptable:
- Add a GUC ssl_compression, defaulting to "on".
- Add a client option "sslcompression" and an environment variable
PGSSLCOMPRESSION, defaulting to "1".
Seems like the reasonable thing, yes.
Compression will be disabled if either side refuses.
I assume OpenSSL takes care of this for us, right? We just have to set the flags on the connection?
--
Magnus Hagander
Me:
http://www.hagander.net/ Work:
http://www.redpill-linpro.com/
