71–80 of 112 posts
In my time as security officer, it was a rare and surprising occurrence when we didn't need to hold an upcoming release due to a pending OpenSSL advisory. It got to the point of the release engineer saying "I think we're ready to start the release builds tomorrow, any news from OpenSSL" and me replying "nothing yet, but I'm sure it will come" -- their timing was absolutely impeccable.
Earlier quoted context omitted.
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…
> It's not Rust, but: golang This is a false choice. Go and Rust are not replacements for each other. They both have qualities which make each better suited for different environments. Rust is actually capable of replacing all uses of C, Go's runtime will generally be an impediment to using it in certain cases. Also I would argue that there are entire classes of bugs that are still available in Go that are not in Rus…
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.
It won't end with Rust either since it is so appealing and easy to jump into unsafe territory.
Earlier quoted context omitted.
You could do the same with C code -- it is getting everyone to follow the policies that is the hard part. Even compiling Rust code in release mode instead of debug removes some essential safety features. Should be clear by now that "policies" just doesn't work, but no, project are repeating the exact same mistake over and over again. :)
The crucial difference is between a policy, which people can not follow (and you might not catch them), and a language or compiler restriction, which people can't work around without doing something drastic like shelling out to a new process, which you can catch (in a well built language).
Earlier quoted context omitted.
Easy is not the same as necessary. At least high-security projects like OpenSSL could enforce a policy of not using unsafe code, and it's easy to validate that there's no unsafe code or that the few known instances are very well vetted.
You could do the same with C code -- it is getting everyone to follow the policies that is the hard part. Even compiling Rust code in release mode instead of debug removes some essential safety features. Should be clear by now that "policies" just doesn't work, but no, project are repeating the exact same mistake over and over again. :)
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…
I've spent a career of 12 years writing, reviewing and breaking C in high-security products such as HSMs. I'm still to see real world, secure C. Maybe you could point me towards the numerous real world examples of people getting this right. I'd prefer scaled-up outcomes here, not just saying 'djb wrote qmail'. (Incidentally, I don't have a quarrel with C specifically. All memory-unsafe languages expand the range of t…
> Kerberos
>broken, obsolete, badly designed, underspecified, dangerous and/or insane
Which list does Kerberos fit in?
Earlier quoted context omitted.
I've spent a career of 12 years writing, reviewing and breaking C in high-security products such as HSMs. I'm still to see real world, secure C. Maybe you could point me towards the numerous real world examples of people getting this right. I'd prefer scaled-up outcomes here, not just saying 'djb wrote qmail'. (Incidentally, I don't have a quarrel with C specifically. All memory-unsafe languages expand the range of t…
Off-topic, but a quick question on your project: > Kerberos >broken, obsolete, badly designed, underspecified, dangerous and/or insane Which list does Kerberos fit in?
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 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 attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything. This reasoning doesn't make s…
The implicit assumption here is that the language isn't at the same time introducing a number of other vulnerabilities. Is there a language you would like to suggest?
Earlier quoted context omitted.
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 would posit another reason you don't have as many issues; you don't have as many people trying to find them. 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.
The crucial difference is between a policy, which people can not follow (and you might not catch them), and a language or compiler restriction, which people can't work around without doing something drastic like shelling out to a new process, which you can catch (in a well built language).
But Rust is ugly and C is beautiful. Why would someone want to work in an ugly language all day?
There's a big difference between arguing for safety and arguing for Rust specifically. Everyone likes some languages and dislikes others. Can you design a safe(r) language that you would consider to be beautiful?