Unexpected EOF handling

[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. Switching on a SSL_OP if that newly provided OP is a
> trivial change to an application that needs to accommodate various
> versions of OpenSSL (and I am not talking about forks), however
> switching on a SSL_OP and also add another special error case is much
> more complicated change and has potential for bringing regressions in
> the applications that need to do it.

Of course, just adding a call to get the old behaviour back is a
very easy change. But I currently don't see how a different error
is that much more complicated.

> Is there really another situation where SSL_ERROR_SYSCALL with errno 0
> could be returned apart from the unclean EOF condition?
> 
> I can't really think of any.

It's not because we can't think of any other case that there aren't
any.

I also have a problem with checking errno being 0. We don't set
errno. There is no reason to assume that errno is set to any
value. errno can be modified on a succesful call. That errno is 0
is just a coincidence. If we're going to document that, we should
actually make sure that that is the case.

I think the other property of the old behaviour is that we don't
add anything to the error stack.

> So I would be just for properly documenting the condition and keeping
> it as is if the SSL_OP to ignore unclean EOF is in effect.

And also don't add an option for applications that do want to get
a fatal error?


Kurt