OpenSSL bug in 5.4.33 and 5.5.17

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

-----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

-----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-----

--

Hi,

That's a bad thing we need to fix ASAP.

I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which
is something we usually don't do (but as this could involve security,
we may do it).
The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if
not part of a 5.6.1RC2 (tag is tomorrow)

5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on
odd weeks whereas 5.5 is on even weeks.

Waiting for Ferenc's advice anyway.

Julien.P

Hi!

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

So, for 5.4 should we revert 6569db8 and 32be79d then? What about
upmerging to 5.5? What about f86b2193, should this be reverted too? I'm
feeling I don't understand what is going on there completely.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/