Re: PHP releases, OPcache + Jit bugs, and communication

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": "k�S0R�;o > �ŝx�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