"OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

Has anyone started a rumor yet that the NSA infiltrated the OpenSSL development team to make OpenSSL ineffective and full of holes?

The convoluted code of OpenSSL alone (from yesterday's Hackernews post) seems like a great way to add all sorts of "bugs" inadvertent or not.

Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA.

Remember that the Snowden docs says that the NSA can break SSL/TLS/https/VPN, etc., but we do not know the full details: http://blog.cryptographyengineering.com/2013/12/how-does-nsa... But the one thing all of these technologies (SSL,TLS,https,VPNs) have in common is usually OpenSSL.

Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy.

That being said I agree that OpenSSL could do with a good code cleaning, but that's a massive undertaking, especially for such a popular library. You have to be backwards compatible.

Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL but for now we have to deal with it.

I disagree.

These are complex to make robust, but they are not hard concepts. I think everyone should write their own GC, write a filesystem, and handle their own memory layer, at least once.

Treating lower levels of the stack as "too complex, there be dragons, just write some Javascript that hits RESTful API for JSON" is a great way to ensure you never progress as a software dev or an engineer.

I agree that reinventing the wheel poorly - without understanding geometry or physics - is a terrible idea. But I also think that we don't have enough people nowadays making toy wheels to learn about geometry and physics.

For each of the things you mentioned, there are concrete and good reasons why they grow complexity: filesystems need to be robust to media corruption and power faults; memory allocators need to be highly tuned to OS and architecture memory layouts; GCs need to be optimized for the code patterns of the particular language they serve, as well as understand the same OS and hardware memory constraints as allocators.

But much of the complexity of these layers is not intrinsic to the problem, and not related to the above. In fact, most of the complexity and bugs of production code at these layers have to do with legacy compatibility, or code inheritance. (If you look at what Theo says about this specific OpenSSL bug, it arises because the OpenSSL team wrote their own allocator that doesn't use malloc() protection bits because those are not compatible across some platforms.)

As the old saying goes: in science, we advance by standing on each others' shoulders; in software, we stand on each others' toes.

To quote Ted Dziuba:

"Anyone who ever told you that swear words have no place in technical discussion is right. They're right, and sadly, they're part of the problem because they miss the point. The sterile word placement that's supposed to support an argument makes any true motivation indistinguishable from all the hired bullshit.

[...]

However, when someone starts swearing in technical discussion, showing emotion, that's a strong indicator that I'm about to receive wisdom. Wisdom is earned the hard way, and it is permanent, not like some statistically shaky performance benchmark that we'll all forget about next week."

I feel the same - I'd rather have people feeling passionate about their work and use swear words, than work with polite non-personalities that don't give a fuck.

It's a massive open source project that's more than 15 years in the making and supports a massive range of architectures and ever-moving standards. Shit happens, we need to figure out how to make sure it won't happen again at this scale, there's really no need for name calling.