I recently checked the Debian PHP 5.4 changelog and found out this message (5.4.45-0+deb7u3 and 5.4.45-0+deb7u4):
* most patches taken from https://github.com/kaplanlior/php-src
Thanks a lot to Lior Kaplan for providing them.
I was very pleased to see my work being used, and I hope this would save other time while providing PHP long term support.
Also, while others do similar work (e.g. Remi from RedHat), it seems I’m the only when that make this over GIT and with full references (e.g. commit info, CVE info and bug number).
Comments and suggestions are always welcome… either mail or even better – a pull request.
A year ago I’ve blogged about people requesting CVE without letting upstream know. On the other hand, per requests from Debian, I’m working on improving PHP upstream CVE request process. For the last few release this means I ask the security list members which issues they think should have CVE and ask for them in parallel to the release being made (usually in the space between the release being tagged publicly and is actually announced).
In the last week, I’ve encountered a case where a few CVE were assigned to old PHP issues without any public notice. The fixes for these issues have been published a year ago (August 2015). And I find out about these assignment through warning published by the distributions (mostly Debian, which I’m close to).
Sometimes things fall between the chairs, and it’s perfectly OK to ask for CVE to make sure security issues do get attention even if time has passed. But after the issues (and fixes) are public, I don’t see a reason to do so without making the request itself public as well. And even if the request wasn’t public, at least notify upstream so this info can be added to the right places. Most of these bug were found out when I started to add sequential number into the CVE search after getting an a notice from Debian for two of the issues.
- CVE-2015-8873 for PHP #69793
- CVE-2015-8874 for PHP #66387
- CVE-2015-8876 for PHP #70121
- CVE-2015-8877 for PHP #70064
- CVE-2015-8878 for PHP #70002
- CVE-2015-8879 for PHP #69975
- CVE-2015-8880 for PHP aa8cac57 (Dec 2015)
And while working on processing these issues for PHP, I also notice they weren’t updated for libGD where appropriate (including recent issues).
Beyond keeping the eco-system up to date, another aspect of publicity is getting opinions from other parties. For example, in the case of CVE-2015-8879, RedHat doesn’t agree with the classification of the bug as security. To give an example of a way things should happen is the request of CVE for PHP 5.5.34 in April, in which the Gentoo security team asked for assignment without upstream knowledge, Debian representative CCs upstream (Thanks!) and also asks CVE for issues covered by Ubuntu, to which the Ubuntu guy then adds some details.
I hope this blog post will reach the anonymous people behind these CVE requests, and also the people assigning them. Without transparency and keeping things in synchronization, the idea of having a centralized location for security warning is not going to accomplish its goals.
I recently joined Linnovate, and while working on one of the open source projects the company produces, we needed to process video content according to NATO’s standard agreement (STANAG) 4609: NATO Digital Motion Imagery Standard.
So I’m happy to introduce our new project: STANAG at https://github.com/linnovate/stanag , also available with NPM (see https://www.npmjs.com/package/stanag).