Re: libpq compression

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Euler Taveira <euler(at)timbira(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq compression
Date: 2012-06-16 15:15:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's not obvious to me that we actually *need* anything except the
>> ability to recognize that a null-encrypted SSL connection probably
>> shouldn't be treated as matching a hostssl line; which is not something
>> that requires any fundamental rearrangements, since it only requires an
>> after-the-fact check of what was selected.

> Maybe I spelled it out wrong. It does require it insofar that if we
> want to use this for compression, we must *always* enable openssl on
> the connection. So the "with these encryption method" boils down to
> "NULL encryption only" or "whatever other standards I have for
> encryption". We don't need the ability to change the "whatever other
> standards" per subnet, but we need to control the
> accept-NULL-encryption on a per subnet basis.

After sleeping on it, I wonder if we couldn't redefine the existing
"list of acceptable ciphers" option as the "list of ciphers that are
considered to provide encrypted transport". So you'd be allowed to
connect with SSL using any unapproved cipher (including NULL), the
backend just considers it as equivalent to a non-SSL connection for
pg_hba purposes. Then no change is needed in any configuration stuff.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-06-16 15:30:38 Re: Pg default's verbosity?
Previous Message Tom Lane 2012-06-16 15:09:19 Re: [patch] libpq one-row-at-a-time API