Re: [PATCH] add ssl_protocols configuration option

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [PATCH] add ssl_protocols configuration option
Дата
Msg-id CABUevExV9tzx43AcFbw5_Zo3nTtB0A2KJ=+Cr9ZtJ-U7UhRzzw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] add ssl_protocols configuration option  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] add ssl_protocols configuration option
Список pgsql-hackers
On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?

No, it would let the user (temporarily) override it.


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

Definitely - it's still very borderline if it's useful.


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

True.


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

The best part would be if we could just leave it up to the SSL
library, but at least the openssl one doesn't have an API that lets us
do that, right? We *have* to pick something...

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
Следующее
От: Steve Singer
Дата:
Сообщение: Re: [PATCH] HINT: pg_hba.conf changed since last config reload