121–130 of 164 posts
Earlier quoted context omitted.
Nothing, per se. But they don't set up softlimits or message size limits by default, both of which you should definitely do... it's just that the values you put in are specific to your situation.
If you have DJB's ego yelling at you that the default configuration is safe, why would you bother setting limits to fix it?
This is why you don't run software that fossilized back in the nineties. Qmail was solid code but hasn't received the support and on-going development it needed. Use postfix instead for a secure MTA.
Integer overflow bug causing manual memory allocation bug leading to RCE. All too common. We need to stop relying on software written in unsafe languages.
Earlier quoted context omitted.
I could trust softlimit all right, but my point was that I wouldn't trust users to wield it correctly.
softlimit is not difficult to use, certainly no more difficult than patch. programs like tinydns-conf for example autmatically generate a run script containing softlimit with a recommended -m setting. maybe qmail needs something similar.
Earlier quoted context omitted.
https://twitter.com/FiloSottile/status/1262854396934791168
Filo is upset that he did not bother to check the code (that originally came from SUPERCOP, a benchmarking tool) he blindly included in go's xcrypto. Here is DJB's tweet: https://twitter.com/hashbreaker/status/1108637226089496577 (regardless, you should not directly encrypt a large amount of data, even nacl suggest against it https://nacl.cr.yp.to/valid.html ) In addition both Filo and Garrett have a bone to pick wit…
Not everything is a simple dichotomy.
The guy is a legend
That's quite interesting because the bug was there and was quite clear, and was not fixed by one of the most brilliant security persons out there (DJB). Maybe here the attitude really was the wrong one, considering how security oriented qmail was since the start, because the simplest possible fix does not seem to demand any other dimension, like complexity or performances.
Earlier quoted context omitted.
Filo is upset that he did not bother to check the code (that originally came from SUPERCOP, a benchmarking tool) he blindly included in go's xcrypto. Here is DJB's tweet: https://twitter.com/hashbreaker/status/1108637226089496577 (regardless, you should not directly encrypt a large amount of data, even nacl suggest against it https://nacl.cr.yp.to/valid.html ) In addition both Filo and Garrett have a bone to pick wit…
Your criticism of the messenger of further evidence of djb's longstanding refusal to deal straightforwardly with security reports is not on topic, IMO. Not everything is a simple dichotomy.
Regarding the salsa20 implementation: I just mentioned in my previous message why this was not a bug and the only reason that people were upset over it was due to Filo's incompetence.
As for evidence of DJB dealing straightforwardly with security reports: https://news.ycombinator.com/item?id=23250748
I think that https://old.reddit.com/r/crypto/comments/72w42c/statement_re... would be a better example of DJB not properly handling security reports.
DJB makes great code, but it always leaves a sour taste to use his code, because he has such a big ego and refuses to admit when he makes a mistake. He can't admit that it's possible to be the best but still make mistakes. I really hate supporting that.
I wish people stopped repeating it over and over. See https://news.ycombinator.com/item?id=23250748
DJB makes great code, but it always leaves a sour taste to use his code, because he has such a big ego and refuses to admit when he makes a mistake. He can't admit that it's possible to be the best but still make mistakes. I really hate supporting that.
> and refuses to admit I wish people stopped repeating it over and over. See https://news.ycombinator.com/item?id=23250748
Earlier quoted context omitted.
Integer overflow bug causing manual memory allocation bug leading to RCE. All too common. We need to stop relying on software written in unsafe languages.
It is about safe and unsafe implementations rather than safe and unsafe languages.