Re: Disable OpenSSL compression

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/