5.4 security only

I'd like to see https://github.com/php/php-src/pull/694 / https://github.com/php/php-src/pull/765 in so FPM in 5.4 will work properly with Apache 2.4.10+'s mod_proxy_fcgi.

David

Hi!

Moving this out of other topics into its own: according to the release
RFC, we should have 5.4 have 2 years of bugfixes & one year of security
fixes. Since 5.4 was released in March 2012, we're already past 2 year
mark. However, we're still have some bugfixes in 5.4, so I'd like to do
this:

• 5.4.32 is released as planned this week, nothing changes there.

• 5.4 branch that is to be 5.4.33 will be the last release that has any
  non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is
  out too, so that would play nice with the "two stable branches, one
  security branch" theme. Starting from that release forward, 5.4 would be
  purely security fixes only branch.

• EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into
  5.4 branch unless they are very important ones (and that is only because
  people may, in theory, have pending patches and we didn't give advance
  notice). Importance would have to be determined somewhat arbitrarily,
  but basically if it works without it, then it's not in, if there's
  serious doubt if it should be in, it's not in, etc. Security issues, of
  course, still allowed in.

This means if somebody has some pending non-security fixes that have to
be in 5.4, the following two weeks are the last call, provided that the
fixes really must be in 5.4.

Any objections/suggested modifications to this plan?

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

Hi!

Moving this out of other topics into its own: according to the release
RFC, we should have 5.4 have 2 years of bugfixes & one year of security
fixes. Since 5.4 was released in March 2012, we're already past 2 year
mark. However, we're still have some bugfixes in 5.4, so I'd like to do
this:

• 5.4.32 is released as planned this week, nothing changes there.

• 5.4 branch that is to be 5.4.33 will be the last release that has any
  non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is
  out too, so that would play nice with the "two stable branches, one
  security branch" theme. Starting from that release forward, 5.4 would be
  purely security fixes only branch.

• EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into
  5.4 branch unless they are very important ones (and that is only because
  people may, in theory, have pending patches and we didn't give advance
  notice). Importance would have to be determined somewhat arbitrarily,
  but basically if it works without it, then it's not in, if there's
  serious doubt if it should be in, it's not in, etc. Security issues, of
  course, still allowed in.

This means if somebody has some pending non-security fixes that have to
be in 5.4, the following two weeks are the last call, provided that the
fixes really must be in 5.4.

Any objections/suggested modifications to this plan?

This seems just right to me.

+1

Julien

2014.08.19. 1:59 ezt írta ("Stas Malyshev" smalyshev@sugarcrm.com):

Hi!

Moving this out of other topics into its own: according to the release
RFC, we should have 5.4 have 2 years of bugfixes & one year of security
fixes. Since 5.4 was released in March 2012, we're already past 2 year
mark. However, we're still have some bugfixes in 5.4, so I'd like to do
this:

• 5.4.32 is released as planned this week, nothing changes there.

• 5.4 branch that is to be 5.4.33 will be the last release that has any
  non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is
  out too, so that would play nice with the "two stable branches, one
  security branch" theme. Starting from that release forward, 5.4 would be
  purely security fixes only branch.

• EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into
  5.4 branch unless they are very important ones (and that is only because
  people may, in theory, have pending patches and we didn't give advance
  notice). Importance would have to be determined somewhat arbitrarily,
  but basically if it works without it, then it's not in, if there's
  serious doubt if it should be in, it's not in, etc. Security issues, of
  course, still allowed in.

This means if somebody has some pending non-security fixes that have to
be in 5.4, the following two weeks are the last call, provided that the
fixes really must be in 5.4.

Any objections/suggested modifications to this plan?

Nope, I think it is a good plan.

• EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into
  5.4 branch unless they are very important ones (and that is only because
  people may, in theory, have pending patches and we didn't give advance
  notice). Importance would have to be determined somewhat arbitrarily,
  but basically if it works without it, then it's not in, if there's
  serious doubt if it should be in, it's not in, etc. Security issues, of
  course, still allowed in.

Hey Stas!

Apparently the fix for #67724 [2] caused #67865 [1], but I already have
a fix for the fix (oh my) [3].

The question is whether to commit the fix or revert e4ff7f2e in 5.4?

https://bugs.php.net/bug.php?id=67865
https://bugs.php.net/bug.php?id=67724
http://pastebin.com/0wJcLqY1

--
Regards,
Mike

Hi Stas

Hi!

Moving this out of other topics into its own: according to the release
RFC, we should have 5.4 have 2 years of bugfixes & one year of security
fixes. Since 5.4 was released in March 2012, we're already past 2 year
mark. However, we're still have some bugfixes in 5.4, so I'd like to do
this:

• 5.4.32 is released as planned this week, nothing changes there.

• 5.4 branch that is to be 5.4.33 will be the last release that has any
  non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is
  out too, so that would play nice with the "two stable branches, one
  security branch" theme. Starting from that release forward, 5.4 would be
  purely security fixes only branch.

• EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into
  5.4 branch unless they are very important ones (and that is only because
  people may, in theory, have pending patches and we didn't give advance
  notice). Importance would have to be determined somewhat arbitrarily,
  but basically if it works without it, then it's not in, if there's
  serious doubt if it should be in, it's not in, etc. Security issues, of
  course, still allowed in.

This means if somebody has some pending non-security fixes that have to
be in 5.4, the following two weeks are the last call, provided that the
fixes really must be in 5.4.

Any objections/suggested modifications to this plan?

A bug has been discovered in SSL-enabled streams, ideally the fix
would go into 5.4.

While the bug touches OpenSSL, it's not a security fix in the
strictest sense, however it is known to cause problems with
non-blocking SSL/TLS-enabled streams in the real world (it's also
theoretically possible, though unlikely, for this to cause issues with
blocking streams).

I have created a trivial patch to fix the bug [1], an explanation of
the nature of the bug and how the fix resolves the problem can be seen
in the commit message and comments in the code. The patch contains no
tests, as it's not possible to reproduce the bug in a reliable manner
due to a dependency on external factors for the bug to appear - things
such as the OS packet scheduler, network latency, MTU may all affect
whether the buggy behaviour occurs.

Does anyone have any objections to this being included in 5.4?

Thanks, Chris

[1] https://github.com/DaveRandom/php-src/commit/d4da5d8c1dae152f7aa5f0dd09b1f29b51f48c89