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
