Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds

Поиск
Список
Период
Сортировка
От Gurjeet Singh
Тема Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds
Дата
Msg-id CABwTF4W5SfX9sbZrvhEuTx1jaNU5okiM88gh5uRLuW3i-dFDqw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, May 26, 2022 at 1:00 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, May 26, 2022 at 1:05 AM Gurjeet Singh <gurjeet@singh.im> wrote:
> > There's an symmetry, almost a diametric opposition, between how SSL

I meant "an asymmetry".

> > initialization error is treated when it occurs during server startup,
> > versus when the error occurs during a reload/SIGHUP. During startup an
> > error in SSL initialization leads to FATAL, whereas during a SIGHUP
> > it's merely a LOG message.
> >
> > I found this difference in treatment of SSL initialization errors
> > quite bothersome, and there is no ready explanation for this. Either a
> > properly initialized SSL stack is important for server operation, or
> > it is not. What do we gain by letting the server operate normally
> > after a reload that failed to initialize SSL stack. Conversely, why do
> > we kill the server during startup on SSL initialization error, when
> > it's okay to operate normally after a reload that is unable to
> > initialize SSL.
>
> I think you're overreacting to a behavior that isn't really very surprising.

The behaviour is not surprising. I developed those opposing views as I
was reading the code. And I understood the behaviour after I was done
reading the code. But I was irked that it wasn't clearly explained
somewhere nearby in code. Hence my proposal:

> > I have added a comment to be_tls_init(), which I hope explains this
> > difference in treatment of errors.

> So I don't really know what behavior, other than what is actually
> implemented, would be reasonable.

I just wasn't happy about the fact that I had wasted time trying to
find holes (security holes!) in the behaviour. So my proposal is to
improve the docs/comments about this behaviour, and not the behaviour
itself.

Best regards,
Gurjeet
http://Gurje.et



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

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: ICU_LOCALE set database default icu collation but not working as intended.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_upgrade test writes to source directory