Public Key Security Vulnerability and Mitigation.
GitHub had quite an interesting experience over the weekend, and it’s worth examining for a number of reasons. First and foremost a security issue was exposed that affected an extremely large number of systems and users.
I’m not a Rails developer but from what I understand, the security issue is one that was brought up and then closed in the past, but many people feel it should require a change to Rails itself. If you’re a Rails developer I would highly suggest researching the issue at hand to determine if your systems are exposed as well.
The second thing to note is the way the issue both occurred and was handled. From what I can see the security notice was brought up in private but suppressed in a way. To overgeneralize, the submitter then piggybacked the exploit in a very visible way on GitHub so as to get the attention he felt it deserved.
It’s interesting to see the reactions from people not only to the submitter’s methods, but GitHub’s response as well, which comes in the form of two posts to the GitHub Blog:
It’s interesting to see the divide in support/offense to both the exploitation of the issue as well as GitHub’s response.
Comments
The security issue was open and closed, because it’s not the responsibility of Rails – it’s the responsibility of the developer (in this case, Github, which they admit). Rails is not an authentication layer, and has done a good job of staying out of that realm. What they provide you is conventions over configuration. Mass assignment is a convention, and their API has shown how to prevent an issue like what happened here. That’s all they can do. They can’t babysit developers, and developers should be aware of the chainsaw and know how to use it so they don’t cut off their arms.
This is different from security exploits in other frameworks, as this isn’t a security exploit. It’s known. It has been known for a while. It’s up to the responsible developers to ensure they protect against mass assignment.
To sum up: This should not be *fixed* in Rails, because it’s not broken. The Rails team can continue to educate and provide different means to protect, but they can’t write your code. With this specific example, it’s not something Rails, at the core, can fix by itself, because it has no idea what your database schema will be – or it’s role in the application. It’s up to the developer to create the schema, and protect it.
I would say the same thing with PHP frameworks. A framework is just that, a framework – it can’t replace a responsible developer.