Can we downvote submissions or something? Because this is absolute rubbish.
There may be an average of 1 error per 1000 lines of code, but saying that there are 299 remaining bugs in OpenSSL is like saying there are sixteen thousand vulnerabilities in the Linux kernel. All software is backdoored if you go by this standard. There would be no such thing as security anymore. So the rule is flawed.
Then another third of the post goes on to complain about the excessive list of CAs in our browser. How does this have anything to do with OpenSSL? What cryptographic breakthrough do you propose we use instead?
Until then, I suppose you just shut up and try to work on the OpenSSL code, or an alternative library, instead of writing blogposts.
Though I really appreciate the shut up and hack mentality, sometimes people have to pick their battles. It might still be appropriate to send a message to the community to draw attention to the issue, in the hope that somebody else has the time to do the hard work. In this case it seems like OpenBSD might be doing that work.
The bug estimates phk gives might not be hard science, but having spent the past few days looking at the OpenSSL code, I think his critique is spot on.
ACM is not a branch of IEEE, they are distinct organizations. Even if it were, ACM Queue is a publication whose authors are not strictly ACM employees. Many are practitioners and researchers in the computing field. In this case, the author's background comes from working on FreeBSD.
Also, this complaint is a bit like the one earlier about the Wired article saying everything should be encrypted being sent over http and not https. The authors are calling for change, the publication's medium is managed by someone else. Your little gripe would be far more appropriate if it were a blog author on their own platform calling for some change but not applying it to their own platform.
It wasn't a gripe per se so much as an ironic observation, but thanks for the correction. (Also ironically: I was a member of ACM for a couple of years -- when my employer paid my dues -- and I did not realize ACM was distinct, versus a part of, IEEE.)
You might have had it mixed up with the IEEE Computer Society. It's the software and computer focused end of IEEE, with the other societies being more focused on other EE fields (power, radio, etc.).
Let's please write the replacement in a language that has some built-in safety guarantees, and ideally some features supporting correctness proofs.
Haskell comes to mind. If we want to avoid a runtime, let's go for a language like Rust, which also has strong safety guarantees and lots of Haskell/ML-inspired features that help improve both safety and readability (advanced pattern matching, Options, immutability guarantees, etc.)
Both of these languages are sufficiently fast to develop high-performance crypto frameworks, and both have good FFIs for calling optimized C code if necessary.
Isn't there a significant tension between the performance impact of using cryptography more widely and the efficiency of the implementations? Let's suppose that implementing low level libraries is 50% or 200% or 500% less efficient than implementing them in C. Now consider that there are good reasons to use these libraries more widely.
Can those memory safe languages be called by other languages? Or moving that library to another language will force python/ruby/etc. to rewrite (a large) part of their own FFI?
Forgive me, but I feel like laughing.
No one helped the project. No one funded the project.
No one cared until the hearthbleed bug. No one even looked at the damned code. But everyone feels entitled to comment on how shitty OpenSSL is, NOW.
This is getting ridiculous.
I forgive your ignorance. Many people have looked at the code and run away screaming, because it is so horrible and evidently upstream does not care as they keep adding horror to it. Many people have sent patches upstream, only to be ignored for years. Phk himself has looked at and criticized the code before Heartbleed, as have many others.
When a bug like this hits the news all around the world, it is a good time to make sure everybody knows it is not just some once-in-a-century instance of the inevitable shit happens in an otherwise good project. Getting everybody to realize it is possible to do better is one step towards making it happen.
12 comments
[ 3.2 ms ] story [ 37.0 ms ] threadThere may be an average of 1 error per 1000 lines of code, but saying that there are 299 remaining bugs in OpenSSL is like saying there are sixteen thousand vulnerabilities in the Linux kernel. All software is backdoored if you go by this standard. There would be no such thing as security anymore. So the rule is flawed.
Then another third of the post goes on to complain about the excessive list of CAs in our browser. How does this have anything to do with OpenSSL? What cryptographic breakthrough do you propose we use instead?
Until then, I suppose you just shut up and try to work on the OpenSSL code, or an alternative library, instead of writing blogposts.
Also, this is a repost:
https://news.ycombinator.com/item?id=7586705
The bug estimates phk gives might not be hard science, but having spent the past few days looking at the OpenSSL code, I think his critique is spot on.
http://ieeelog.dragusin.ro/init/default/log
Also, this complaint is a bit like the one earlier about the Wired article saying everything should be encrypted being sent over http and not https. The authors are calling for change, the publication's medium is managed by someone else. Your little gripe would be far more appropriate if it were a blog author on their own platform calling for some change but not applying it to their own platform.
Haskell comes to mind. If we want to avoid a runtime, let's go for a language like Rust, which also has strong safety guarantees and lots of Haskell/ML-inspired features that help improve both safety and readability (advanced pattern matching, Options, immutability guarantees, etc.)
Both of these languages are sufficiently fast to develop high-performance crypto frameworks, and both have good FFIs for calling optimized C code if necessary.
When a bug like this hits the news all around the world, it is a good time to make sure everybody knows it is not just some once-in-a-century instance of the inevitable shit happens in an otherwise good project. Getting everybody to realize it is possible to do better is one step towards making it happen.