Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112283
MIME-Version: 1.0
References: <CA+kxMuSVHBeWNTG=Wor2NP9WkbY7FGqhtUJaqYeS7T-hqoQ-8A@mail.gmail.com>
In-Reply-To: <CA+kxMuSVHBeWNTG=Wor2NP9WkbY7FGqhtUJaqYeS7T-hqoQ-8A@mail.gmail.com>
Date: Tue, 24 Nov 2020 22:32:24 +0100
Message-ID: <CADyq6sKZK9FVTxkwPwk6Yre5gAikJb2M7eNtYPqiCjBqcMNs0Q@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008f015505b4e10cc3"
Subject: Re: [PHP-DEV] PHP releases, OPcache + Jit bugs, and communication
From: ocramius@gmail.com (Marco Pivetta)

--0000000000008f015505b4e10cc3
Content-Type: text/plain; charset="UTF-8"

Hey Dan,
<http://ocramius.github.com/>


On Tue, Nov 24, 2020 at 9:48 PM Dan Ackroyd <Danack@basereality.com> 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/

--0000000000008f015505b4e10cc3--