VERIFY_NONE
A while back, it came to my attention that ruby's net/https implementation had an insecure default: not verifying TLS certificates (OpenSSL::SSL::VERIFY_NONE). I wrote an article about it for RubyInside, and helped @geemus fix the issue in his excon gem. Despite this being an incredibly serious security issue, nobody really seemed to care. Oh well.
Then today, one of the biggest names in the ruby community, Aaron Patterson (aka @tenderlove), posted a gist of a little campfire bot that he wrote that forced net/https in to this insecure mode.
Yes, a campfire bot is relatively unimportant security-wise (except that if there's a man-in-the-middle, he now has credentials to access your campfire room, which may or may not contain company secrets — but I digress). Eventually I remarked that despite the relative unimportance of a campfire bot, tenderlove is a leader in the ruby community, and leaders should set good examples.
A few other people also responded. @joedamato posted an admittedly less constructive response. And Ben Black, a somewhat snarky, but not particularly harsh suggestion. That's when the hate started pouring in.
Here's the thing: this is a very serious security issue, and nearly every rubygem that uses net/http is guilty of it (yes, even active_merchant, the thing that everybody uses to interact with payment gateways). Why? Because of the prevelance of copy and paste coding. Yes, I do it, and so do you.
And nearly every net/https example uses VERIFY_NONE. It's so common in example code that in the related links on the RubyInside article about the perils of VERIFY_NONE, there's a link to example code that uses it (lol?).
Aaron is one of a small group of people in the ruby community who actually has the power to do something about this problem. By setting the right example, people will copy and paste good code instead of bad code. That's more useful than a million tweets or blog posts.
Yes, this may all seem trivial to you. It's just a hack, after all. Obviously, Aaron wasn't being deliberately insecure. He was just hacking, which is perfectly fine. But, we all know that hacks have a way of ending up in production.
It probably won't be tenderlove's app; it might be some noob who found and modified his code. But sometimes one man's hack winds up (however indirectly) being another man's business.