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
