> 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 >>>>> #define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL" >>>>> 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: http://www.postgresql.org/mailpref/pgsql-hackers