Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112282
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-ID: <9e902c98-8d97-4401-9dd1-29607dd6eff8@www.fastmail.com>
In-Reply-To: 
 <CA+kxMuSVHBeWNTG=Wor2NP9WkbY7FGqhtUJaqYeS7T-hqoQ-8A@mail.gmail.com>
References: 
 <CA+kxMuSVHBeWNTG=Wor2NP9WkbY7FGqhtUJaqYeS7T-hqoQ-8A@mail.gmail.com>
Date: Tue, 24 Nov 2020 15:04:18 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] PHP releases, OPcache + Jit bugs, and communication
From: larry@garfieldtech.com ("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