Re: Unexpected EOF handling

2020-05-11 Thread Kurt Roeckx
On Mon, May 11, 2020 at 06:38:40PM +0300, Dmitry Belyavsky wrote: > Dear Tomas, > > I'm not sure this is the best possible solution because it makes the > application developers doing extra compile-time checks. This is a very minimal change they they need to do that doesn't have much risk. But

Re: Unexpected EOF handling

2020-05-11 Thread Dmitry Belyavsky
Dear Tomas, On Mon, May 11, 2020 at 2:07 PM Tomas Mraz wrote: > On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote: > > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > >

Re: Unexpected EOF handling

2020-05-11 Thread Tomas Mraz
On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > > So I think we need at least to agree on: > > > > - Do we want an

Re: Unexpected EOF handling

2020-05-08 Thread Kurt Roeckx
On Fri, May 08, 2020 at 01:27:00PM +0300, Dmitry Belyavsky wrote: > On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote: > > > > So I think the suggestion is to have this: > > - By default, SSL_ERROR_SSL is returned with > > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be > > marked

Re: Unexpected EOF handling

2020-05-08 Thread Dmitry Belyavsky
Dear Kurt On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote: > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > > So I think we need at least to agree on: > > > > - Do

Re: Unexpected EOF handling

2020-05-08 Thread Kurt Roeckx
On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > So I think we need at least to agree on: > > > - Do we want an option that makes the unexpected EOF either a fatal > > >

Re: Unexpected EOF handling

2020-05-07 Thread Matt Caswell
On 07/05/2020 20:28, Dmitry Belyavsky wrote: > From my point of view, if we don't revert the change for the sake of API > clarity, we need to provide an option restoring old behaviour at least > for test purposes. Presumably nginx can already handle the situation where a close_notify *is*

Re: Unexpected EOF handling

2020-05-07 Thread Dmitry Belyavsky
Hello, I want to draw everybody's attention to the position (and argumentation) of Nginx developers: === As already mentioned by Dmitry, we here at nginx don't think the change was necessary. As Matt already said above in the comments to SSL_CONF_cmd.pod change, the error was always

Re: Unexpected EOF handling

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 15:45 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote: > > Actually the coincidence is that the errno is set to 0 on EOF. So > > yes, > > we should explicitly clear the errno on EOF so any leftover value > > from > > previous calls does

Re: Unexpected EOF handling

2020-05-07 Thread Kurt Roeckx
On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote: > > Actually the coincidence is that the errno is set to 0 on EOF. So yes, > we should explicitly clear the errno on EOF so any leftover value from > previous calls does not affect this. On EOF, errno is normally not modified. It's

Re: Unexpected EOF handling

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 14:53 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote: > > From application developer side of view for protocols that do not > > depend on SSL detecting the truncation I think inventing a > > different > > behavior for this condition

Re: Unexpected EOF handling

2020-05-07 Thread Kurt Roeckx
On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote: > From application developer side of view for protocols that do not > depend on SSL detecting the truncation I think inventing a different > behavior for this condition than the existing one as of 1.1.1f would be > clearly wrong.

Re: Unexpected EOF handling

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > So I think we need at least to agree on: > > - Do we want an option that makes the unexpected EOF either a fatal > > error or a non-fatal error? > > - Which error should we return? > > This

Re: Unexpected EOF handling

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 13:22 +0200, Kurt Roeckx wrote: > Hi, > > We introduced a change in the 1.1.1e release that changed how we > handled an unexpected EOF. This broke various software which > resulted in the release of 1.1.1f that reverted that change. > In master we still have the 1.1.1e

Re: Unexpected EOF handling

2020-05-07 Thread Matt Caswell
On 07/05/2020 12:22, Kurt Roeckx wrote: > So I think we need at least to agree on: > - Do we want an option that makes the unexpected EOF either a fatal > error or a non-fatal error? > - Which error should we return? This is an excellent summary of the current situation. I am not keen on

Unexpected EOF handling

2020-05-07 Thread Kurt Roeckx
Hi, We introduced a change in the 1.1.1e release that changed how we handled an unexpected EOF. This broke various software which resulted in the release of 1.1.1f that reverted that change. In master we still have the 1.1.1e behaviour. The change itself is small, it just calls SSLfatal() with a