4 ms·

> The only code you can be completely certain is correct is the code you didn't have to write. Not true at all, there are always compiler errors, and in many c

> The only code you can be completely certain is correct is the code you didn't have to write. Not true at all, there are always compiler errors, and in many cases you can statically check your code using an external validation system. I'd be 99.999% confident of most of the WRITTEN code of SEL-4, probably more confident than ANY code "not written" in rust, because it's been formally verified by a theorem-proving external system that enforces far more invariants that the rust compiler. To be dramatic, the rust compiler after all will not throw a fit if you write fn add(a: i32, b: i32) -> i32 { a - b; } but if that kind of a mistake happened in the SEL-4 codebase you bet your butt the theorem prover would be unhappy. Correctness also can be other things that you might not be able to lean on the compiler to check so easily. For example, cryptographic side channels (timing e.g.). If there is ANY ambiguity caused by the inexplicitness of the code you produce, maybe because you're not thinking about the cost of the destruction event, because, after all, you didn't write it, and there's not lexical artifact left over, it can get extremely challenging to audit for those sorts of things.

ncmncm 5y ago
Anybody who cannot tell whether a type has a destructor is qualified neither to code nor to audit cryptographic primitives. In any case, cryptographic timing behavior is verified by careful white-box testing, not just inspection. Any bonus destructor activity (if, e.g., somebody unqualified coded it) would show up then. When your case is so weak, it is better not to present it.
- jorangreef 5y ago
  "doing almost everything right to become essential infrastructure, but will need to add some equivalent of destructors to get there." To be fair, if we come back to this opening argument, I'm still wondering how strong the premise here is? Are destructors in fact essential to essential infrastructure as you claim in your view? I'm not sure that I'm convinced by the case as you've presented it so far. I don't think we need to look too far to find counter-examples of essential infrastructure with the highest levels of safety that achieve this safety without destructors, and where destructors would be precluded by the safety model. Also, as someone who's done a fair amount of security work, the timing safe argument against hidden control flow is at least compelling and something to explore and not ignore out of hand. If a language design can make crypto simpler and safer to implement correctly, then I would say that's already a good indication of what the language may be able to do for less complex domains.

ncmncm 5y ago

Anybody who cannot tell whether a type has a destructor is qualified neither to code nor to audit cryptographic primitives. In any case, cryptographic timing behavior is verified by careful white-box testing, not just inspection. Any bonus destructor activity (if, e.g., somebody unqualified coded it) would show up then. When your case is so weak, it is better not to present it.

jorangreef 5y ago
"doing almost everything right to become essential infrastructure, but will need to add some equivalent of destructors to get there." To be fair, if we come back to this opening argument, I'm still wondering how strong the premise here is? Are destructors in fact essential to essential infrastructure as you claim in your view? I'm not sure that I'm convinced by the case as you've presented it so far. I don't think we need to look too far to find counter-examples of essential infrastructure with the highest levels of safety that achieve this safety without destructors, and where destructors would be precluded by the safety model. Also, as someone who's done a fair amount of security work, the timing safe argument against hidden control flow is at least compelling and something to explore and not ignore out of hand. If a language design can make crypto simpler and safer to implement correctly, then I would say that's already a good indication of what the language may be able to do for less complex domains.