Lukas Kahwe Smith recently brought forward an idea to PHP-FIG with two broad objectives for a new PSR:
1. To write a security policy that could be adopted by members; and
2. A proposal to make sharing security vulnerabilities more common and standardised.
He has invited interested people to express their interest in joining a separate mailing list to discuss the details: https://groups.google.com/forum/#!topic/php-fig/45AIj5bPHJ4
Larry Garfield of Drupal and Korvan Szanto of concrete5 CMS have offered to sponsor the proposal.
A security policy is essentially a plan of action, where you lay out your expected responses to a reported vulnerability (and your expectations of all parties’ behaviour) in a document for easy reference by your contributors, security reporters and users. An extremely short example:
Will confirm issues; Will fix them consistently; Will inform users when fixed.
A security policy can be as simple or as complicated as you wish, so long as you don’t forget these three core statements. A common problem in PHP open source is when you have a project where a) there is no security policy published and b) the contributors clearly have no informal security policy that they can explain. When both of these points are true, trust becomes an issue. Usually, it can be illustrated by sending in a batch of reports and monitoring the response. When you come back months later and the fixes are still pending despite one or more follow ups, then you simply never use that project. This is ignoring that you had a “batch” to start with .
I like Lukas’ proposal for a standardised security policy in some form since it would help create shared community expectations. Projects can adopt it as a best practice. Security reporters can refer to it to set expectations of projects. Users can rely on it as evidence that a project does actually have a plan of action in the event of vulnerabilities being reported or discovered.
Also, it would just save folk time trying to write their own. All you’d need to put somewhere is “we follow PSR-X” with a reporting email, e.g. your Github README. It doesn’t get any simpler .
Standardised Vulnerability Data
You’ve just adopted an <80 character Security Policy suggested by some lunatic on the internet, and you’re now wondering how to inform users of security vulnerabilities. If you have a website, you might publish a regular blog and RSS feed. If you’re stuck with Github, you might label or prefix commit messages. Email might not be a bad idea. We’ve just mentioned four specific disclosure routes and we can already assume that most users might never become aware of a disclosure. Wouldn’t it be easier to just push the information down to them more consistently?
It’s not an impossible task for the future, but it does rest on the notion that vulnerability data will be available in some agreed format containing specific data. Those with blogs might decorate their feeds appropriately, and those reliant on a simple git repository might just push disclosure data to a basic JSON/YAML file.
What would be achieved through such a practice, is to create lots of vulnerability disclosure data, in standardised formats, that future services and tools could then aggregate and summarise for users based on their known project dependencies. I hesitate to bring Composer/Packagist into the equation, but something along those lines scanning installed (or declared) dependencies for vulnerable versions would be ideal.
A quick Twitter check shows that most tweets recently mentioning PHP-FIG have veered towards the less than impressed end of the spectrum, and I can’t blame those folk who are either disgusted at recent discussions or staking out marshmallows for when the flames rise up again. As I stated in a thread yesterday, I’m currently embarrassed by my association with the group. Whether people like it or not, the conduct of the group casts a shadow on all of its members, and I don’t want its dancing fires of madness reflecting on me.
The list is being overrun by emotionally charged language, derailed threads, personalised attacks, ad-hoc rule enforcement, one-upmanship, and a zero-compromise attitude when debating. In between these, real work is getting done. However, this gets a fraction of the attention, publicity and participation.
If folk want to contribute something useful, Lukas Kahwe Smith is proposing some security related standards (which may go forward as PSR-8 if/when an acceptance vote is organised). Matthew Weier O’Phinney and others are powering through the PSR-7 HTTP messages proposal. There’s other PSRs in progress too! PSR-6 for a caching interface and PSR-5 for a PHPDoc Standard.
The outcome of these “dramas” is to hide all of this good work behind a wall of horse manure. This crap also alienates potential contributors, discourages collaboration, and turns us into a laughing stock on social media. In fact, I’m feeling like I’ve heard something like this before…
There’s an ongoing joke between many people who follow PHP internals development (or used to follow) that it is a toxic kindergarten.
- Anthony Ferrara: http://blog.ircmaxell.com/2013/09/rambling-on-internals.html
Yes, it’s time to invoke Anthony “Sir Clarity” Ferrara. Run ye for yonder hills. Anthony makes a bunch of useful points that apply to PHP-FIG just as they do to PHP Internals so it’s well worth re-reading that article and ruminating on its contents. While closing that article, Anthony makes the most obvious point of all:
…unless people realize and talk about the problems, they can never be solved.
Going back on threads for the past few months, I’ve listed a set of “rules” that people have mentioned or, at least, never objected to. I would ask PHP-FIG members to a) read them, b) make comments if they want, c) suggest additions, d) consider a +1, and e) consider calling out people if they breach them.
Let’s start diverting some of this high energy effort into PSRs…