Magnus Hagander <magnus@hagander.net> writes:
> If anything, I think the default should be "default", and then we have
> that map out to something. Because once you've initdb'ed, the config
> file wil be stuck with a default and we can't change that in a minor
> release *if* something like POODLE shows up again. It would require an
> admin action, and in this case, it would make us less secure. If we
> had a GUC that took the keyword "default" which would mean "whatever
> the current version of postgresql thinks is the best" then we could
> change the default in a security update if something showed up.
That's pretty much isomorphic to just setting the value in the code,
no?
> Having the guc could certainly be useful in some cases. If we do, we
> should of course *also* have a corresponding configuration option in
> libpq, so I'd say this patch is incomplete if we do want to do it.
True. But both of those scenarios posit that no *code* changes are
needed, which is infrequently the case.
And you still have the problem that if an admin does change the setting
away from "default", and forgets to revert that after his next update,
he could in the long run be less secure not more so. Client-side
settings would likely be even harder to get rid of than server-side.
And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will have exactly
the same perspective with regards to *our* values. And not without
reason; we were forcing very obsolete settings up till recently,
because nobody had looked at the issue for a decade. I see no reason
to expect that that history won't repeat itself.
regards, tom lane
