91–100 of 112 posts
Earlier quoted context omitted.
> 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…
> Use a language that makes a bunch of security flaws impossible 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?
That is a preposterous argument.
Earlier quoted context omitted.
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?
There are no standard kerberos ciphersuites that use anything better than RC4/IDEA/DES/3DES: http://www.iana.org/assignments/tls-parameters/tls-parameter... . So: broken and obsolete.
So .. progress is being made.
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.
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. :)
What essential safety features are removed? The only thing I can think of this referring to is assertions, and we do the opposite: assert stays in all builds, debug_assert is only in debug builds.
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…
Not to mention I would argue memory exhaustion bugs like this happen in memory safe garbage collected languages frequently too.
Earlier quoted context omitted.
What essential safety features are removed? The only thing I can think of this referring to is assertions, and we do the opposite: assert stays in all builds, debug_assert is only in debug builds.
Integer overflow checking, for example.
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…
I think OpenBSD beg to differ. Not to mention I would argue memory exhaustion bugs like this happen in memory safe garbage collected languages frequently too.
Earlier quoted context omitted.
LibreSSL isn't up to speed yet? http://www.libressl.org
It certainly wasn't when I was Security Officer -- it didn't exist yet. I believe some people are working on bringing libressl into the FreeBSD base system, but there are some challenges; for example, FreeBSD supports stable branches for 5 years, while libressl follows OpenBSD's "break everything once a year" model.