Re: [PATCH] configure-time knob to set default ssl ciphers

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(dot)eisentraut(at)2ndquadrant(dot)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.

Pavel

> 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
> >
>
>