From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, Euler Taveira <euler(at)timbira(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq compression |
Date: | 2012-06-20 15:44:18 |
Message-ID: | F62D7FF2-EEA8-4EE3-B20D-0EE424212469@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun20, 2012, at 17:34 , Tom Lane wrote:
> Florian Pflug <fgp(at)phlo(dot)org> writes:
>> I wonder though if shouldn't restrict the allowed ciphers list to being
>> a simple list of supported ciphers. If our goal is to support multiple
>> SSL libraries transparently then surely having openssl-specific syntax
>> in the config file isn't exactly great anyway...
>
> No, we don't want to go there, because then we'd have to worry about
> keeping the default list in sync with what's supported by the particular
> version of the particular library we chance to be using. That's about
> as far from transparent as you can get. A notation like "DEFAULT"
> is really quite ideal for our purposes in that respect.
No argument with that, but does that mean we have to allow the full
syntax supported by OpenSSL (i.e., those +,-,! prefixes)? Maybe we could
map an empty list to DEFAULT and otherwise interpret it as a list of
ciphers?
It'd make the whole NULL-cipher business easy, because once we know that
the cipher specified doesn't contain !NULL (which removes NULL *permanently*),
we can simply append NULL to allow "all these ciphers plus NULL".
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-06-20 15:47:14 | Re: Nasty, propagating POLA violation in COPY CSV HEADER |
Previous Message | Robert Haas | 2012-06-20 15:44:09 | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node |