Re: [HACKERS] [PATCH] configure-time knob to set default ssl ciphers
От | Pavel Raiskup |
---|---|
Тема | Re: [HACKERS] [PATCH] configure-time knob to set default ssl ciphers |
Дата | |
Msg-id | 4835729.atG9sx83cK@nb.usersys.redhat.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] configure-time knob to set default ssl ciphers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [PATCH] configure-time knob to set default ssl ciphers
|
Список | pgsql-hackers |
On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@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. Thanks! Pavel > It looks like the xxx_flush_after GUCs aren't exactly fully documented > as to this point, so we have some work to do there too :-( > regards, tom lane >
В списке pgsql-hackers по дате отправления: