5 ms·

The problem with #3 (Abstract C with libraries.) is that, while there are less place / code to audit, in case of failure (e.g. a security hole in said library),

The problem with #3 (Abstract C with libraries.) is that, while there are less place / code to audit, in case of failure (e.g. a security hole in said library), damages are everywhere. A good exemple is Daniel J. Bernstein. The man doesn't even trust the libc and wrote its own layer for all of his software (djbdns, qmail, ...). (source : http://cr.yp.to/qmail/guarantee.html http://cr.yp.to/qmail/guarantee.html #7)

jessaustin 13y ago
Libraries are so bad that DJB has to write his own? What are you trying to say?
- paraboul 13y ago
  I'm not saying anything. He is. I think there is a good balance between using third party library (possibly untrusted) and plain C. Kind of an analogy to centralized network vs decentralized.
  - jessaustin 13y ago
    So far as I can see TFA isn't even insisting on third party libs (even though he himself has released e.g. "a sane dynamic string library"); he just wants a refactoring, so that overflows and other problems are avoided in DRY fashion, using libraries. memcpy() isn't quite as smelly as gets(), but a well-designed library can certainly help even expert coders use it more safely. I can't see how the DJB example supports the claim that "damages are everywhere". It's trivial to say that there could conceivably be a "balance" here (what human activity doesn't include the concept of balance?), but a cursory glance suggests that OpenSSL code is currently far from that point.
dllthomas 13y ago
Though with the "weakest link" dynamics, I'm not sure "damages are everywhere" isn't a feature. If your library primitives are supposed to be designed such that they can only be used safely, and if there is a flaw in your primitives, the fact that everything uses those same primitives means that there's more testing of that same code in different situations, and so "damages are everywhere" means that errors are more likely to show up in some test. That is on top, of course, of DRY naturally shrinking the code that needs the most carefully audited.
bch 13y ago
Exibit a: OpenSSL library providing encryption... On the surface, a tricky problem.

jessaustin 13y ago

Libraries are so bad that DJB has to write his own? What are you trying to say?

paraboul 13y ago
I'm not saying anything. He is. I think there is a good balance between using third party library (possibly untrusted) and plain C. Kind of an analogy to centralized network vs decentralized.
- jessaustin 13y ago
  So far as I can see TFA isn't even insisting on third party libs (even though he himself has released e.g. "a sane dynamic string library"); he just wants a refactoring, so that overflows and other problems are avoided in DRY fashion, using libraries. memcpy() isn't quite as smelly as gets(), but a well-designed library can certainly help even expert coders use it more safely. I can't see how the DJB example supports the claim that "damages are everywhere". It's trivial to say that there could conceivably be a "balance" here (what human activity doesn't include the concept of balance?), but a cursory glance suggests that OpenSSL code is currently far from that point.

dllthomas 13y ago

Though with the "weakest link" dynamics, I'm not sure "damages are everywhere" isn't a feature. If your library primitives are supposed to be designed such that they can only be used safely, and if there is a flaw in your primitives, the fact that everything uses those same primitives means that there's more testing of that same code in different situations, and so "damages are everywhere" means that errors are more likely to show up in some test. That is on top, of course, of DRY naturally shrinking the code that needs the most carefully audited.

bch 13y ago

Exibit a: OpenSSL library providing encryption... On the surface, a tricky problem.