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 :
In 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)
resolves the issue. As long as that works as expected I can merge that and
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-----
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
