> On 08 Feb 2017, at 13:31, Pavel Raiskup <prais...@redhat.com> wrote:
> On Wednesday, February 8, 2017 1:29:19 PM CET Pavel Raiskup wrote:
>> On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote:
>>> Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
>>>> On 2/7/17 11:21 AM, Tom Lane wrote:
>>>>> A compromise that might be worth considering is to introduce
>>>>> into pg_config_manual.h, which would at least give you a reasonably
>>>>> stable target point for a long-lived patch.
>>>> You'd still need to patch postgresql.conf.sample somehow.
>>> Right.  The compromise position that I had in mind was to add the
>>> #define in pg_config_manual.h and teach initdb to propagate it into
>>> the installed copy of postgresql.conf, as we've done with other GUCs
>>> with platform-dependent defaults, such as backend_flush_after.
>>> That still leaves the question of what to do with the SGML docs.
>>> We could add some weasel wording to the effect that the default might
>>> be platform-specific, or we could leave the docs alone and expect the
>>> envisioned Red Hat patch to patch config.sgml along with
>>> pg_config_manual.h.
>> Thanks for quickt feedback.  Just to not give up too early, I'm attaching
>> 2nd iteration.  I'm fine to fallback to pg_config_manual.h solution though,
>> if this is considered too bad.
>> I tried to fix the docs now (crucial part indeed) so we are not that
>> "scrict" and there's some space for per-distributor change of ssl_ciphers
>> default.
>> From the previous mail:
>>> I'm not really sure that we want to carry around that much baggage for a
>>> single-system hack.
>> Accepted, but still I'm giving a chance.  OpenSSL maintainers predict this 
>> (or
>> something else in similar fashion) is going to be invented in OpenSSL 
>> upstream.
>> So there's still some potential in ./configure option.
> Argh :( !  Attaching now and sorry.

Since we hopefully will support more SSL libraries than OpenSSL at some point,
and we don’t want a torrent of configure options, wouldn’t this be better as
--with-server-ciphers=STRING or something similar?  

+   --with-openssl-be-ciphers=STRING
+                           Replace the default list of server-supported ciphers

Each SSL implementation would then be responsible for handling it appropriately.

cheers ./daniel

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to