GitHub has been compromised. That, by itself, is important enough – with millions of projects and developers using it. But there is more to it. Have a look at these links:
- LWN report and discussion
- Original GitHub blog posting
- Follow-up GitHub blog posting
- A nice overview of what actually happened
- Description of the relevant Rails issue
There is more coverage all over the web, but I’m sure you know how to find your way around. Now, to the lessons that we can learn from what happened.
- “Don’t panic” in big friendly letters, courtesy of Hitchhiker’s Guide to the Galaxy. It’s obvious something out of the ordinary happened in GitHub’s routine life. While they regained the clarity of mind pretty fast, they were caught off-guard. Don’t panic is the first rule of panic situations.
- Pay attention! Given the size and active lives of both GitHub and Rails, it’s difficult to pay attention to every little detail. But you should always weight the “large number of installations” or “large user base” considerations. Even if there is an issue with a documented feature. We’ve seen examples of this again and again – something that was a part of original functionality once in a while is turned into a malicious attack vector. Your answer shouldn’t be the simple “check your code”.
- Stay transparent. As you can see from a few comments in the above links, the actual compromise is not the biggest deal. People in general and software developers in particular are very much used to security issues in every software. It happens. The bigger deal is, of course, how you handle that. When you obviously have a problem, don’t try to hide it or misinform people who rely on you. Say it loud and clear. Or you will lose trust.
- Mind the stack. Today’s computing world is rather complex. Most projects rely on third-party libraries, tools, and solutions. And that’s a good thing. But when you do that, don’t treat the third-party item as a black box. That is especially frequent in Open Source Software development. It’s easy to trust something that is open. It’s free, it’s open, it’s secure and reliable. Not always the case. And sometimes it is the case, but you need to read the documentation and think carefully. As much as you are concerned about the security of your own code, there is no guarantee that the libraries, framework, or even the language compiler that you are using are secure. Keep that in mind.
With all that, what’s my attitude to GitHub now? It’s still the same. I love the service and I trust the company. Everybody makes mistakes. Not everybody learns from them. When things like that happen, I’m always willing to give a second chance (and sometimes even the third). Maybe I’m just hoping that when I screw up people won’t just turn away. Maybe I’m just an optimist – who knows. But GitHub still provides the service that I enjoy using. No matter the compromise, I (or any of my projects) haven’t been affected. And I think that GitHub will learn from this experience. So I don’t see any reason to change my attitude.