3 ms·

Agreed, there's no realistic way to port OpenSSL to a new language. What I'm saying is, I think a clean-up fork of OpenSSL will divide the workforce per project

by fab13n 13y ago

Agreed, there's no realistic way to port OpenSSL to a new language. What I'm saying is, I think a clean-up fork of OpenSSL will divide the workforce per project, without dramatically improving security. So it's not "dumb", but I expect the net result to be negative. At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great.

sigzero 13y ago
I don't agree at all. I am betting that once LibreSSL is "done" it will get adopted heavily and the community will have a cleaner and more secure code base to work from going forward.
- deegles 13y ago
  I trust the OpenBSD team to get it right.
  - clarry 13y ago
    I'm going to quote somebody out of context. Please bear with me... What I am seeing is that we have a ridiculously upside-down trust model -- "Trust the developers". We never asked for people to trust us. We might have "earned some" in some people's eyes, but if so it has always been false, even before this. People should trust what they test, but the world has become incredibly lazy. We build this stuff by trusting each other as friends, and that is done on an international level. If anything, the layers and volume of trust involved in software development should decrease trust. Oh right, let's hear some of that "many eyes" crap again. [..] All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code. If anything, the collaborative model we use should _decrease_ trust, [..] Before anyone gets the wrong idea, I'm not trying to attack any individual here. But so many software vulnerabilities, goto fail included, Heartbleed included, have caused such angry response from people. That the bug was trivial. It should've been caught by static analysis, smart compilers, correct review process, careful third party readers, TDD, UFOs, ADHD, <insert favorite tech here>. It is easy to say all that in hindsight, because you are for most part right. So why weren't these techniques used? You can't blame the developers for everything, they have work on their hands and you are not entitled to anything more from them. You also can't trust developers. If there's sloppy code, someone has to notice it and point it out. Someone has to fix it. If there are sloppy development practices and it is evident that the upstream developers do not care, someone has to notice that and let the world know. Then maybe create a fork and try to do better. So anyone capable of reviewing code and diffs: please try to do it if you haven't before. Try to do more if you're already doing it. And remeber, you do not have to be an expert programmer to notice a duplicated goto fail line. Or if you can write tests, why don't you contribute? [quote] http://marc.info/?l=openbsd-tech&m=129261032213320&w=2 http://marc.info/?l=openbsd-tech&m=129261032213320&w=2
peterwwillis 13y ago
> At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great There are no guarantees of anything working out or being great, regardless of technology. And whatever language/tech you use would require a couple of layers of control. For example, ensuring the low-level features of the language don't betray entropy to statistical analysis, or managing (and ensuring) the virtual memory used is cleaned up properly, or being as efficient as possible lest the crypto become a performance barrier to use. It's not like high level languages can't implement crypto as well as lower level ones; they can. But it's a lot easier to ensure the various attack vectors are mitigated in a low-level language where there's no glue [outside of that included in your source] to get in the way, obscure, or otherwise subvert the security and performance of the applications using your code. The Heartbleed bug happened because the glue they chose to use was crappy; this was an implementation problem, not a low-level-language problem.

by fab13n 13y ago

sigzero 13y ago

I don't agree at all. I am betting that once LibreSSL is "done" it will get adopted heavily and the community will have a cleaner and more secure code base to work from going forward.

deegles 13y ago
I trust the OpenBSD team to get it right.
- clarry 13y ago
  I'm going to quote somebody out of context. Please bear with me... What I am seeing is that we have a ridiculously upside-down trust model -- "Trust the developers". We never asked for people to trust us. We might have "earned some" in some people's eyes, but if so it has always been false, even before this. People should trust what they test, but the world has become incredibly lazy. We build this stuff by trusting each other as friends, and that is done on an international level. If anything, the layers and volume of trust involved in software development should decrease trust. Oh right, let's hear some of that "many eyes" crap again. [..] All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code. If anything, the collaborative model we use should _decrease_ trust, [..] Before anyone gets the wrong idea, I'm not trying to attack any individual here. But so many software vulnerabilities, goto fail included, Heartbleed included, have caused such angry response from people. That the bug was trivial. It should've been caught by static analysis, smart compilers, correct review process, careful third party readers, TDD, UFOs, ADHD, <insert favorite tech here>. It is easy to say all that in hindsight, because you are for most part right. So why weren't these techniques used? You can't blame the developers for everything, they have work on their hands and you are not entitled to anything more from them. You also can't trust developers. If there's sloppy code, someone has to notice it and point it out. Someone has to fix it. If there are sloppy development practices and it is evident that the upstream developers do not care, someone has to notice that and let the world know. Then maybe create a fork and try to do better. So anyone capable of reviewing code and diffs: please try to do it if you haven't before. Try to do more if you're already doing it. And remeber, you do not have to be an expert programmer to notice a duplicated goto fail line. Or if you can write tests, why don't you contribute? [quote] http://marc.info/?l=openbsd-tech&m=129261032213320&w=2 http://marc.info/?l=openbsd-tech&m=129261032213320&w=2

peterwwillis 13y ago

> At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great There are no guarantees of anything working out or being great, regardless of technology. And whatever language/tech you use would require a couple of layers of control. For example, ensuring the low-level features of the language don't betray entropy to statistical analysis, or managing (and ensuring) the virtual memory used is cleaned up properly, or being as efficient as possible lest the crypto become a performance barrier to use. It's not like high level languages can't implement crypto as well as lower level ones; they can. But it's a lot easier to ensure the various attack vectors are mitigated in a low-level language where there's no glue [outside of that included in your source] to get in the way, obscure, or otherwise subvert the security and performance of the applications using your code. The Heartbleed bug happened because the glue they chose to use was crappy; this was an implementation problem, not a low-level-language problem.