PHP releases, OPcache + Jit bugs, and communication View as Markdown

Hi internals,

Currently the PHP project doesn't have a particularly great way of
letting users know when serious defects have been found in versions of
PHP.

My understanding is that this has been an issue before, when defects
were found in OPcache. Due to OPcache incorrectly optimizing code,
bugs could spontaneously appear anywhere in users code. As we had
nothing in place, we didn't have a way of communicating 'the latest
version is borked, avoid it' Fortunately there were few incidents of
this.

However, the JIT is quite likely to have many similar issues, where
either new issues, or regressions, could seriously affect the
integrity of how data is processed in PHP applications.

I'd like to suggest that this could be improved by having some machine
readable data somewhere (see example below), that contains a list of
known critical issues that people should know about before upgrading
to a particular version of PHP.

This would at least allow people to either hold off on upgrading from
a version that works, to a known bad version, as well as do things
like alert their ops team of investigating whether a newly found issue
could be affecting their programs, and it might be appropriate for
them to revert to a previous version of PHP.

Thoughts? And does anyone know of any projects that already do this,
so we can be inspired by their best practices?

cheers
Dan
Ack

btw before anyone suggests "why don't we just have more releases?",
PHP is mostly distributed through package managers on a fixed
schedule. Switching to an ad-hoc schedule would be a huge amount of
work for many people, and doesn't like a reasonable thing to do.

Example of data

[
{
"version": "8.0.1",
"issues": [
{
"link": "https://bugs.php.net/bug.php?id=12345";,
"affects": "jit"
}
]
},
{
"version": "8.0.0",
"issues": [
{
"link": "https://bugs.php.net/bug.php?id=12345";,
"affects": "opcache"
}
]
}
]

The 'affects' entry could be a comma separated list of things such as:

jit - the JIT
opcache - opcache
php - the core engine with/without JIT or OPcache.
security - known security flaws that of a severity that justify an
urgent upgrade

That was essentially the idea behind the FIG's PSR-9:

https://github.com/php-fig/fig-standards/blob/master/proposed/security-disclosure-publication.md

It unfortunately never really went anywhere, but I thought it was a good idea. There's some links there to some prior art we were drawing from, or planning to draw from. The idea was to allow projects to publish a link to a feed of security releases in their composer.json, and then Composer (or a plugin) could audit your dependencies and tell you if one of them was busted.

My ideal was an Atom feed, as then it's compatible with pub/sub, but not everyone agreed with me about that. :-)

--Larry Garfield

Hey Dan,
http://ocramius.github.com/

Hi internals,

Currently the PHP project doesn't have a particularly great way of
letting users know when serious defects have been found in versions of
PHP.

My understanding is that this has been an issue before, when defects
were found in OPcache. Due to OPcache incorrectly optimizing code,
bugs could spontaneously appear anywhere in users code. As we had
nothing in place, we didn't have a way of communicating 'the latest
version is borked, avoid it' Fortunately there were few incidents of
this.

However, the JIT is quite likely to have many similar issues, where
either new issues, or regressions, could seriously affect the
integrity of how data is processed in PHP applications.

I'd like to suggest that this could be improved by having some machine
readable data somewhere (see example below), that contains a list of
known critical issues that people should know about before upgrading
to a particular version of PHP.

This would at least allow people to either hold off on upgrading from
a version that works, to a known bad version, as well as do things
like alert their ops team of investigating whether a newly found issue
could be affecting their programs, and it might be appropriate for
them to revert to a previous version of PHP.

Thoughts? And does anyone know of any projects that already do this,
so we can be inspired by their best practices?

cheers
Dan
Ack

btw before anyone suggests "why don't we just have more releases?",
PHP is mostly distributed through package managers on a fixed
schedule. Switching to an ad-hoc schedule would be a huge amount of
work for many people, and doesn't like a reasonable thing to do.

Example of data

[
{
"version": "8.0.1",
"issues": [
{
"link": "https://bugs.php.net/bug.php?id=12345";,
"affects": "jit"
}
]
},
{
"version": "8.0.0",
"issues": [
{
"link": "https://bugs.php.net/bug.php?id=12345";,
"affects": "opcache"
}
]
}
]

The 'affects' entry could be a comma separated list of things such as:

jit - the JIT
opcache - opcache
php - the core engine with/without JIT or OPcache.
security - known security flaws that of a severity that justify an
urgent upgrade

An rss/atom feed with affected version ranges (can be added via XSD, I
suppose) would be fantastic: I'd factor it into roave/security-advisories
ASAP, if there was a way to have such a thing :-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/