4 ms·

Some examples of poor quality of code? This has not been my experience. I've gone through the code base a couple of times for my own education and to do some sm

by geertj 9y ago

Some examples of poor quality of code? This has not been my experience. I've gone through the code base a couple of times for my own education and to do some small patches, and I found it clean and easy to read.

zAy0LfpBZLC8mAC 9y ago
The problem isn't so much "typical programming errors", but the appoach to solving problems. So, it's not that there are tons of buffer overflows in the code (well, not that I know of, though I didn't explicitly look for them either), but stuff such as the vulnerabilities in the DNS resolver because they reimplemented things from scratch without the necessary domain knowledge on how to do that securely that has been collected and implemented by the dozens of existing implementations over the decades, or the bug that caused .* to match .. and thus systems to be destroyed by the temp cleanup code, which is equally a potential pitfall that is well-documented and explicitly even standardized against in POSIX, but they still failed to implement this in a way that is both evidently sane and also otherwise generally accepted to be the correct way to do things ... and then they even pretended that it's somehow not actually a bug. Those are two somewhat recent examples I can think of, but there have been many more showing the same kind of attitude. They are ignoring hard-earned knowledge on how to do things securely, safely and reliably, they ignore the intentions of abstractions, and they pretend that obvious bugs aren't bugs because there is some weird way to reinterpret the bug into being correct behaviour (that noone expects and that causes harm).
- deleted 9y ago
  [deleted]
- someone12345 9y ago
  > stuff such as the vulnerabilities in the DNS resolver because they reimplemented things from scratch without the necessary domain knowledge on how to do that securely that has been collected and implemented by the dozens of existing implementations over the decades By domain knowledge how to do this securely in implementations tested oer time, do you mean something like https://access.redhat.com/articles/2161461 https://access.redhat.com/articles/2161461? It doesn't look like systemd's resolver fares worse in comparison... In addition it can be sandboxed (and is), an advantage over having a resolver part of libc.
  - zAy0LfpBZLC8mAC 9y ago
    Thank you for the demonstration, that is indeed roughly what that lack of domain knowledge combined with arrogance looks like. Would you mind explaining how exactly sandboxing prevents cache poisoning?

by geertj 9y ago

zAy0LfpBZLC8mAC 9y ago

The problem isn't so much "typical programming errors", but the appoach to solving problems. So, it's not that there are tons of buffer overflows in the code (well, not that I know of, though I didn't explicitly look for them either), but stuff such as the vulnerabilities in the DNS resolver because they reimplemented things from scratch without the necessary domain knowledge on how to do that securely that has been collected and implemented by the dozens of existing implementations over the decades, or the bug that caused .* to match .. and thus systems to be destroyed by the temp cleanup code, which is equally a potential pitfall that is well-documented and explicitly even standardized against in POSIX, but they still failed to implement this in a way that is both evidently sane and also otherwise generally accepted to be the correct way to do things ... and then they even pretended that it's somehow not actually a bug. Those are two somewhat recent examples I can think of, but there have been many more showing the same kind of attitude. They are ignoring hard-earned knowledge on how to do things securely, safely and reliably, they ignore the intentions of abstractions, and they pretend that obvious bugs aren't bugs because there is some weird way to reinterpret the bug into being correct behaviour (that noone expects and that causes harm).

deleted 9y ago
[deleted]
someone12345 9y ago
> stuff such as the vulnerabilities in the DNS resolver because they reimplemented things from scratch without the necessary domain knowledge on how to do that securely that has been collected and implemented by the dozens of existing implementations over the decades By domain knowledge how to do this securely in implementations tested oer time, do you mean something like https://access.redhat.com/articles/2161461 https://access.redhat.com/articles/2161461? It doesn't look like systemd's resolver fares worse in comparison... In addition it can be sandboxed (and is), an advantage over having a resolver part of libc.
- zAy0LfpBZLC8mAC 9y ago
  Thank you for the demonstration, that is indeed roughly what that lack of domain knowledge combined with arrogance looks like. Would you mind explaining how exactly sandboxing prevents cache poisoning?