FriendsOfPHP/security-advisories

Report security-affected php versions?

Ocramius opened this issue ยท 10 comments

From what I can see, the repository contains no information about security advisories for PHP versions or PHP extensions.

While I know the ecosystem is hugely messed up here (because of linux LTS distros that just "invent" a new versioning system for backported security patches), it would still be a good idea to just report any PHP release that does reference a CVE.

I think this would hugely improve the push for deploying latest stable releases.

Thoughts?

cebe commented

not sure whether this fits into the scope of this repository. This one is mostly about checking your existing composer.json/lock against security issues, not the server env.

mfdj commented

From a userland perspective I think expanding the scope to the PHP-runtime and extensions would be beneficial and provide visibility into the importance of security issues.

I think it is a great idea. Especially if you see the statistic from this Blog Posts https://developerjack.com/blog/2015/12/09/php-version-roundup/

stof commented

the issue is that the checker tool takes a composer.lock as input currently.

Checking security issues in PHP and extensions would require a separate tooling (sending info about the PHP version and extensions instead). So it probably belongs to a separate repository (which may still be hosted in this organization though), with a separate checker backend.
Unless @fabpot wants to extend the scope of https://security.sensiolabs.org/ of course

I'm ๐Ÿ‘ for adding information about PHP security issues. But keep in mind that the SensioLabs security checker is a tool used in dev/staging/testing envs, so, probably not the right tool to warn you about PHP issues.

Anyway, having everything centralized seems like a good idea. Then, tools can read and consume this information as they see fit.

The problem is always the same one: what about ancient dinosaurs like Debian Oldstable and RedHat enterprise pain? They don't expose composer-friendly PHP versions with fixes, sadly.

While I appreciate the effort, I don't think it's worth it. There are too many Linux distros with their own versions and PHP itself has good enough announcements for new security updates.

I asked on the Ubuntu packaging channel before, why they release their own versions instead of following upstream, and the only response was, that upstream does probably suck and break things in bugfix releases.

While PHP does have had breaking changes in minor versions, I think the risk of breaking changes in patch versions is rather low and compared to the security benefit, it's totally worth following upstream for patch releases. Would be cool if we could encourage distros to follow our patch releases at least.

reiz commented

There are already different security databases out there which track that. For example the Debian security-tracker. The problem with them is that they are platform dependent. Having a new datasource which only takes tags/versions from upsource into account is an idea I like a lot! I would love to integrate that into VersionEye.

The main input for VersionEye is the composer.json/composer.lock file. To make that Git & CI Integration work we would have to rely on meta information in the composer.json file. There could be a plugin which is reading meta information about the current PHP runtime and updating that information in the composer.json. Or it could be tracked in a separate file. In Ruby projects we have for example a .ruby-version file.

Maybe we could start by looking at every well-known linux distro and gather here the list of urls which can be used for each to ascertain all the vulns in all the versions of php they released over time and the subsequent patches? We could maybe also ask Jordi if he has OS/php stats gathered by Composer, to get a feeling of which coverage percentage we would be reaching in term of OS...

Closing this issue as after thinking again about this, I think it's something related but at the same time very different.