3 ms·

You mean to say me that there’s no such thing as “superior programming practices”./s I’d take a heavily used and tested system over one programmed “with superi

You mean to say me that there’s no such thing as “superior programming practices”./s I’d take a heavily used and tested system over one programmed “with superior practices”, like obsoleting rarely used code, any day of the week. Yes, heartbleed was bad, but those type of bugs are rare, and once made public patches come fast. You don’t make your system more secure by exchanging the rare occasional general bug with obscure and unknown bugs (with unknown reach). A lot of people thinking in security tend to fall for the availability bias, they want to protect themselves from the bugs that make news, while ignoring the ones that are removed day by day in a changelog of some minor utility they are using.

MaxBarraclough 6y ago
I'd say it depends. > heartbleed was bad, but those type of bugs are rare Not really. There's a constant stream of security vulnerabilities arising from buffer-overflows and memory-management bugs, even in the most high-profile C/C++ codebases like the Linux kernel and Chromium. C and C++ are minefields for undefined behaviour, and many security vulnerabilities can be tracked back to instances of undefined behaviour. Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. That's not to say I'd uncritically jump aboard a safe-Rust replacement for OpenSSL. As you say, there's much value in mature and battle-tested code, and Rust's safety guarantees wouldn't guarantee you a bug-free SSL library, they only guarantee the absence of certain kinds of errors. Even a fully formally verified implementation in SPARK could still have side-channel vulnerabilities (e.g. timing issues).
- xondono 6y ago
  Bugs are frequent, but most of them have limited scope, bugs that break everything from computers to smart toasters are rare. As a C programmer myself I’m well aware of how big the mine field is, and I’m a big proponent for validation in the Rust style, but that was not the point. This guide advocates for replacements for programs and libraries written in C++, with most of those replacements being written also in C++, but with “superior programming practices”, even when those replacements are very rarely used in most environments.
  - MaxBarraclough 6y ago
    Even there it depends. 'Programming practices' is vague. Even C can be tamed, at great expense, using formal methods techniques. [0][1][2][3] Adoption of such methods can give a solid assurance of the lack of UB, like use of a safe language. Weaker measures, like adopting MISRA C, don't provide such strong assurances (although they can eliminate certain categories of errors), and as you indicate, their real value is a bit more subjective. Mandating a bad programming style could actively make things worse. [0] https://trust-in-soft.com/ https://trust-in-soft.com/ [1] https://www.eschertech.com/products/perfect_developer.php https://www.eschertech.com/products/perfect_developer.php [2] https://github.com/microsoft/Armada https://github.com/microsoft/Armada [3] https://www.microsoft.com/en-us/research/project/vcc-a-verifier-for-concurrent-c/ https://www.microsoft.com/en-us/research/project/vcc-a-verif...
- nineteen999 6y ago
  > Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. Unfortunately this is easier said than done, as evidenced by the fact that it is said a lot, and never done.
  - MaxBarraclough 6y ago
    Agree. Not something I know a lot about but it seems to be a significant undertaking. I figure a production-grade implementation in safe Rust is more likely than a verified implementation in SPARK. I don't know how serious the rustls implementation is. Nice to see it makes no use of Rust's unsafe features. https://github.com/ctz/rustls https://github.com/ctz/rustls

MaxBarraclough 6y ago

I'd say it depends. > heartbleed was bad, but those type of bugs are rare Not really. There's a constant stream of security vulnerabilities arising from buffer-overflows and memory-management bugs, even in the most high-profile C/C++ codebases like the Linux kernel and Chromium. C and C++ are minefields for undefined behaviour, and many security vulnerabilities can be tracked back to instances of undefined behaviour. Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. That's not to say I'd uncritically jump aboard a safe-Rust replacement for OpenSSL. As you say, there's much value in mature and battle-tested code, and Rust's safety guarantees wouldn't guarantee you a bug-free SSL library, they only guarantee the absence of certain kinds of errors. Even a fully formally verified implementation in SPARK could still have side-channel vulnerabilities (e.g. timing issues).

xondono 6y ago
Bugs are frequent, but most of them have limited scope, bugs that break everything from computers to smart toasters are rare. As a C programmer myself I’m well aware of how big the mine field is, and I’m a big proponent for validation in the Rust style, but that was not the point. This guide advocates for replacements for programs and libraries written in C++, with most of those replacements being written also in C++, but with “superior programming practices”, even when those replacements are very rarely used in most environments.
- MaxBarraclough 6y ago
  Even there it depends. 'Programming practices' is vague. Even C can be tamed, at great expense, using formal methods techniques. [0][1][2][3] Adoption of such methods can give a solid assurance of the lack of UB, like use of a safe language. Weaker measures, like adopting MISRA C, don't provide such strong assurances (although they can eliminate certain categories of errors), and as you indicate, their real value is a bit more subjective. Mandating a bad programming style could actively make things worse. [0] https://trust-in-soft.com/ https://trust-in-soft.com/ [1] https://www.eschertech.com/products/perfect_developer.php https://www.eschertech.com/products/perfect_developer.php [2] https://github.com/microsoft/Armada https://github.com/microsoft/Armada [3] https://www.microsoft.com/en-us/research/project/vcc-a-verifier-for-concurrent-c/ https://www.microsoft.com/en-us/research/project/vcc-a-verif...
nineteen999 6y ago
> Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. Unfortunately this is easier said than done, as evidenced by the fact that it is said a lot, and never done.
- MaxBarraclough 6y ago
  Agree. Not something I know a lot about but it seems to be a significant undertaking. I figure a production-grade implementation in safe Rust is more likely than a verified implementation in SPARK. I don't know how serious the rustls implementation is. Nice to see it makes no use of Rust's unsafe features. https://github.com/ctz/rustls https://github.com/ctz/rustls