Bug 1394677

Summary:	Change in 1.1.0c contradicts docs and breaks perl-IO-Socket-SSL test suite
Product:	[Fedora] Fedora	Reporter:	Paul Howarth <paul>
Component:	openssl	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	cheimes, tmraz, vondruch
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openssl-1.1.0c-3.fc26	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-30 13:31:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul Howarth 2016-11-14 08:23:19 UTC

After updating from 1.1.0b to 1.1.0c (in Fedora Rawhide), perl-IO-Socket-SSL's tests fail (https://apps.fedoraproject.org/koschei/package/perl-IO-Socket-SSL?collection=f26). Upstream's response is:

  I think this is a bug in OpenSSL, introduced in
  https://github.com/openssl/openssl/commit/4880672a9b41a09a0984b55e219f02a2de7ab75e.
  This commit changes the documented API on SSL_read so that it now return -1
  on EOF with a claimed syscall error instead of 0 as it did before and as is
  documented. When reverting this commit everything works again. See also
  https://github.com/openssl/openssl/issues/1903.

This means for now I hope that OpenSSL fixes the issue so that the behavior matches again the documented API.

Comment 1 Tomas Mraz 2016-11-14 13:40:09 UTC

There is currently discussion upstream in the GitHub issue above but it seems that the problematic thing is the actual documentation.

Comment 2 Tomas Mraz 2016-11-14 17:13:50 UTC

*** Bug 1394892 has been marked as a duplicate of this bug. ***

Comment 3 Paul Howarth 2016-11-17 13:58:21 UTC

Looks like upstream has decided to revert to the previous behavior for now (see the GitHub issue mentioned earlier).

Comment 4 Tomas Mraz 2016-11-21 08:52:40 UTC

Sure, but the revert is not yet merged into the 1.1.0 branch. I am waiting for that. Also it's clear from the upstream discussion that application code that relies on SSL_read() return value difference between 0 and -1 is wrong and it should always call SSL_get_error() to test for retryability so although this will be reverted sooner or later the application code should be also eventually patched in preparation for 1.1.1.

Comment 5 Paul Howarth 2016-11-21 09:57:29 UTC

Upstream of perl-IO-Socket-SSL has now addressed this (in 2.039); perhaps #1394892 should be re-opened for the other cases, and this ticket closed?

Comment 6 Tomas Mraz 2016-11-22 10:10:27 UTC

I've included the upstream revert in openssl-1.1.0c-2.fc26

Comment 7 Vít Ondruch 2016-11-30 13:16:41 UTC

Re-opening. The patch is not applied to make this really fixed ...

Comment 8 Tomas Mraz 2016-11-30 13:33:46 UTC

For clarification: Real fix must be in the applications - they have to follow the doc as patched in the revert patch. The code revert itself makes them work - it is a workaround, but this behavior is accidental, depending on the underlying BIO behavior, and not something the applications should depend on.

Comment 9 Christian Heimes 2016-11-30 15:19:18 UTC

Tomas, I'm also the maintainer of CPython's ssl module. Python 3.6.0 will be released soon, but I don't have time to work on a fix any time soon. Do you have time to assist?

Comment 10 Tomas Mraz 2016-11-30 15:47:01 UTC

Note there is no hurry in implementing the real fix as the revert will stay in 1.1.0 and most probably also in the next release. The behaviour might change in future though.