On 16-06-2012 00:43, Magnus Hagander wrote: > For example, we can no longer trust the SSL library to always do > encryption, since we specifically want to support null encryption. > Meaning we need to teach pg_hba to treat a connection with null > encryption as hostnossl, even if it's an openssl-backed connection, > and mirrored. And in libpq, we have to make sure that a requiressl > connection *does* fail even if we have ssl, when we're using null > encryption. And we currently have no way to specify different > encryption options on a per-host basis, which is something we'd have > to do (e.g. i want to be able to say that "subnet x requires > encryption with these encryptions methods" and "subnet y doesn't > require encryption but should do compression". Which in the easiest > first look would require ssl_ciphers to be controllable from > pg_hba.conf - but that doesn't work since we don't get to pg_hba.conf > until after we've negotiated the SSL mode... > > So there's quite a bit of complexity that needs to be put in there > just to deal with the fact that we're using SSL to do compression, if > we want to support it in a way that's not hackish. > That's exactly the complexity I wouldn't add to the code. I'm in favor of experimenting an standard algorithm (zlib, for example -- let's say, it is the easiest way to implement it) or even hooks (libpq and backend -- that seems to be complex but less than openssl-backed connection just for compression).
-- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
