Re: [PHP-DEV] PHP releases, OPcache + Jit bugs, and communication

[Marco Pivetta]

Hey Dan,



On Tue, Nov 24, 2020 at 9:48 PM Dan Ackroyd  wrote:

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

Re: [PHP-DEV] PHP releases, OPcache + Jit bugs, and communication

[Larry Garfield]

On Tue, Nov 24, 2020, at 2:47 PM, Dan Ackroyd wrote:
> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP releases, OPcache + Jit bugs, and communication

[Dan Ackroyd]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php