61–70 of 112 posts
If it does not have a home page and a catchy name like "Heartbleed", then this bug does not exist.
There's one in the advisory for CVE-2016-2183 - https://sweet32.info . I'm trying to track these sites, mainly for my own amusement: https://github.com/KeenRivals/Bugsite-Index
My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.
I maintain a project ( http://freeradius.org ) which a similar amount of code, and (arguably) similar complexity. While we've had issues, they aren't as numerous as OpenSSL. And, the issues in the latest major version are negligible. Why? We have a requirement for code quality. The code can't just work, it has to make sense. The OpenSSL people don't seem to care about badly formatted and/or non-understandable code. A…
I think it is pretty foolhardy to assume that just because security issues haven't been found means they don't exist.
Earlier quoted context omitted.
I hope I don't come across too harsh. Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides of C_. Constantly complaining about C isn't going to get anyone anywhere. It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not…
It's not Rust, but: https://golang.org/pkg/crypto/tls/ I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice. Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang. Non-C…
My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.
Short answer: unlikely to end anytime soon, but likely that we start to focus on higher level bugs more than lower level issues. Long answer: If Unix and C hadn't won the fight in the 1980s like VHS did, we wouldn't deal with such low-level bugs. It took 30 years, but we're finally getting CPUs (like lowRISC) that were inspired by BS5000 or i960 and the languages to go with it are getting mainstream. To be fair, had…
You're writing on a computer magnitudes faster than the fastest computers of the 70s, with significant compiler improvement to boot.
Until about 10 years ago, hand crafted Assembler was still faster than C, and the speed improvements were actually needed.
This "let's write a text editor which is pretty much an advanced nano/pico in JS and have it take up 145MB" is only possible when everyone has a supercomputer in their hands anyways
My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.
I maintain a project ( http://freeradius.org ) which a similar amount of code, and (arguably) similar complexity. While we've had issues, they aren't as numerous as OpenSSL. And, the issues in the latest major version are negligible. Why? We have a requirement for code quality. The code can't just work, it has to make sense. The OpenSSL people don't seem to care about badly formatted and/or non-understandable code. A…
Luckily I moved everything to openbsd's libressl which is /mostly/ compatible. I wonder if this bug affects them, typically the HIGH's haven't[0] It really feels like every other week there is a bug in OpenSSL and after following along with the libressl blog I understand why- the code is an absolute mess[1] [0] http://undeadly.org/cgi?action=article&sid=20150319145126 [1] http://opensslrampage.org/page/49
Not much seems to have happened in LibreSSL since the initial rage-sprint. For now, watch this spot: https://marc.info?l=libressl&r=1&b=201609&w=2
Where did you get that impression?
https://github.com/libressl-portable/openbsd/commits/master shows an actively developed project
Earlier quoted context omitted.
(Just my opinion) I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No. C is the way it is towards secure coding because there are compromises to satisfy other dimensions. is either making huge sacrifices in these other dimensions or is at best an experiment. We understand C's weak p…
What are the sacrifices being made by, say, Rust? I'm only superficially familiar with Rust, but my understanding was that it was basically "C with strong memory guarantees". I naively thought that its entire purpose was to avoid such trade-offs.
It's a bit more upfront work to satisfy the compiler but I've found the payoff in debugging memory issues to be completely worth it.
Earlier quoted context omitted.
We can't burn the world down and remake it. These things WILL happen over time, the next generations definitely are focused on safety and correctness. 1 we need to remove unsafe-machismo for the landscape, vector that energy into correctness instead of living with danger. 2, we need to figure out how to partition, segment, wrap the unsafe legacy stuff into a safe operating regime. The single biggest win is if we coul…
> The single biggest win is if we could load a library in another process and make cross-process calls to it. What? Setting aside the fact that this can already be done in numerous different ways on many platforms, how is this a win? It's hard enough for developers to write correct code, let alone maintaining the correctness of that code while loading and executing unknown code from other parties (see web browsers, a…
Earlier quoted context omitted.
Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.
I hope I don't come across too harsh. Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides of C_. Constantly complaining about C isn't going to get anyone anywhere. It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not…
(Incidentally, I don't have a quarrel with C specifically. All memory-unsafe languages expand the range of terrible vulnerabilities available to the engineer. This is not defensible these days, in my view.)
> So please, pave the road and show us the safer OpenSSL-rust you have.
My contribution here is https://github.com/ctz/rustls
Earlier quoted context omitted.
What are the sacrifices being made by, say, Rust? I'm only superficially familiar with Rust, but my understanding was that it was basically "C with strong memory guarantees". I naively thought that its entire purpose was to avoid such trade-offs.
Certain things(circular structures) are harder to represent without dropping down to unsafe code(which is a C equivalent security model). It's a bit more upfront work to satisfy the compiler but I've found the payoff in debugging memory issues to be completely worth it.