Skip site navigation (1) Skip section navigation (2)

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
Message-ID: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group