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

On Thu, May 26, 2022 at 1:00 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, May 26, 2022 at 1:05 AM Gurjeet Singh <gurjeet(at)singh(dot)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