Re: OpenSSL bug in 5.4.33 and 5.5.17
| From: | Arjen Schol | Date: | Mon, 22 Sep 2014 07:22:59 +0000 |
| Subject: | Re: OpenSSL bug in 5.4.33 and 5.5.17 | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77430@lists.php.net to get a copy of this message | ||
I noticed a regression in 5.5.17RC1, reported it (#67965) and it got fixed in f86b2193 on the 5.5 branch by Daniel Lowrey.
But this fix didn't make it in 5.5.17 final. I posted the following message on the 5.5.17RC1 release announcement:
What's the benefit of doing a Release Candidate/QA cycle when fixes for regressions aren't merged to the final release? See https://bugs.php.net/bug.php?id=67965 Regression reported and fixed, but fix not merged to 5.5.17 branch. Commit https://github.com/php/php-src/commit/f86b2193a483f56b0bd056570a0cdb57ebe66e2f?diff=unified File in 5.5.17: https://github.com/php/php-src/blob/PHP-5.5.17/ext/openssl/xp_ssl.c#L884 Not critical enough? Just missed it? RC releases just for the show? :?Who is resposible for cherrypicking fixes for regressions in release candidates? The release manager? The developer who commited the fix? Did the release manager ever considered including this fix in the final version? Where are regressions tracked? The issues tracker didn't have a 'PHP5.5.15RC1' version, so bugs are filled against '5.5Git-2014-09-05' which makes it difficult to track issues specific on 5.5.17RC1. PHP 5.6.1.RC1 however, IS listed as a version on https://bugs.php.net/report.php The releaseprocess RFC (https://wiki.php.net/rfc/releaseprocess) does not address these issues. Arjen On 09/19/2014 06:49 PM, Remi Collet wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 19/09/2014 18:25, Daniel Lowrey a écrit :resolves the issue. As long as that works as expected I can merge that andIn an effort to fix a very old (seven years old) DoS vulnerability involving encrypted streams I created a regression where feof() notifications on encrypted sockets are broken. This is present in both the most recent 5.4.33 and 5.5.17 releases.Can you please point us to the related commit... (which one cause the regression, which ones are useful)In 5.4.33 and 5.5.17 an immediate fix is to revert these commits: http://git.php.net/?p=php-src.git;a=commitdiff;h=6569db88081562f68a4f79e52cba83482bdf05fc http://git.php.net/?p=php-src.git;a=commitdiff;h=372844918a318ad712e16f9ec636682424a65403 http://git.php.net/?p=php-src.git;a=commitdiff;h=32be79dcfa1bc5af8682d9f512da68c5b3e2cbf3 The last of these (32be79d) has already been fixed upstream by f86b2193a483f56b0bd056570a0cdb57ebe66e2f but this change did not go into 5.4.33 and 5.5.17. Any reverts should also consider f86b2193.Does a revert of the first enough to get back to previous behavior?Yes, reverting the above commits above will fix any issues. I'm awaiting word from someone associated with Horde to verify that the previously linked patch ( https://bugs.php.net/patch-display.php?bug=41631&patch=bug41631.patch&revision=1411139621)everything should be resolved going forward.After a quick check 6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1 f86b219 and 3728449 are in 5.6.1RC1 only -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQcXrUACgkQYUppBSnxahgfigCfUYmoYXJJYC0JKmLi/tg+mo1r mwwAoNXbDpPsdrVfzFWUy4tuOssqR256 =OUHp -----END PGP SIGNATURE-----