7 ms·

It's not "they", it's Daniel J. Bernstein. That's the reason :) (If you don't know: he is a top cryptographer that can amazingly correct code. However, he also

It's not "they", it's Daniel J. Bernstein. That's the reason :) (If you don't know: he is a top cryptographer that can amazingly correct code. However, he also has a very big ego...)

DominoTree 6y ago
I just found this on Wikipedia where he raised his bug bounty and at the same time cited these "unexploitable" bugs https://en.wikipedia.org/wiki/Qmail#Security_reward_and_Georgi_Guninski's_vulnerability https://en.wikipedia.org/wiki/Qmail#Security_reward_and_Geor...
stevekemp 6y ago
qmail was essentially unmaintained for a long time, people were distributing patches to it, but there were no upstream releases. (Similar story with djbdns/tinydns.) "Recently" he released his code with new licenses, so that people could finally start distributing updated versions, rather than the previous approach where lots of people were sharing conflicting patches for various features (e.g. IPv6 support for AAAA records in tinydns.)
- rurban 6y ago
  notqmail.org is for long the defacto maintained version. They had this fixed long time ago.
koheripbal 6y ago
I don't understand. Most people with a big ego would not want a critical vulnerability associated with them. Can you elaborate?
- loeg 6y ago
  His ego has transcended objective reality and he claimed (in 2005, and continues to claim in 2020) it isn't a vulnerability.
- kbenson 6y ago
  he had such confidence in his software and abilities that he thought it was actually secure, and there were no bugs, and posted a bounty for any exploit that could be found. Patching it means acknowledging it's an exploit, and that his code was not without bugs. Given that his principles of writing secure software (included in the Qmail guarantee[1]) includes this: "7. Write bug-free code." that might be a bit hard for him to swallow. 1: https://cr.yp.to/qmail/guarantee.html https://cr.yp.to/qmail/guarantee.html
  - rurban 6y ago
    Well, he used it with memory limits command line switches, so it could never be exploited. So he was technically correct. One should not use so much memory for a mail server, way too risky. Problem is, these switches were not default, people didnt use it because they are dumb, and DJB never cared to properly maintain it. like limiting memory per default, 32bit only builds or such.
    - kbenson 6y ago
      > Problem is, these switches were not default, people didnt use it because they are dumb Pushing complexity from a very small group (in this case, one person) who knows the system intimately to many orders of magnitude more people that are meant to have a functional knowledge of how it operates but not necessarily be intimate with it is a losing proposition, and not any tenet of how I would consider developing secure software. If the software is only supposed to be run under process limits, and over a specific process limit all bets are off security wise, then the program should probably check and report problems with large process limits when it starts. Or, as you posit, dying if built for 64 bit, since its assumptions don't necessarily hold.
    - kelnos 6y ago
      My opinion on this is that if you're going to claim that you write the most secure software in the world, it should be secure by default. It shouldn't require you to modify the configuration in a particular way, or start it in a particular way, in order to be secure. The more details you need to know in order to secure something, more less likely you'll tick off all those boxes. To me, this is just DJB's ego not allowing him to admit that he made mistakes.
- mcguire 6y ago
  He asserted that it was unexploitable, and thus not a vulnerability. Fixing the code would have implied that it might have been a vulnerability, and he might have been wrong. Can't have that.
vinay_ys 6y ago
http://cr.yp.to/talks/2007.11.02/slides.pdf http://cr.yp.to/talks/2007.11.02/slides.pdf I don't see ego in these slides. I see a brilliant programmer acknowledging his mistakes and learning from them. I really enjoyed running qmail in early 2000s and following djb's crypto work later. He is brilliant indeed.
- cadence- 6y ago
  You should read some of his public.... ekhm... “discussions” with Wietse Venema on various security forums in the 90’s. It was very entertaining, but also clearly showcasing djb’s huge ego.
  - reaperducer 6y ago
    A lot of it would get you banned from HN and similar fora today.
- cadence- 6y ago
  Here is my favourite that I remember to this day: https://seclists.org/bugtraq/1998/Nov/117 https://seclists.org/bugtraq/1998/Nov/117
  - Snelius 6y ago
    Hah, "How many people relaxed after installing tcpd -DPARANOID, instead of pestering their vendors for a real fix?" Sounds similar here ;)
    - Quekid5 6y ago
      Yeah, the lack of self-reflection is pretty palpable.
kelnos 6y ago
The funny thing about that is I find his code to be very difficult to read (even just the snippets in the linked CVE illustrate this). And his attitude is just bonkers to me. "I'm not going to fix this exploitable security issue because I assume that people will configure their environment in a particular way." What? That's... flat-out irresponsible.
- dependenttypes 6y ago
  He does not have any responsibility against anyone. He released his software in public domain with the source included for free.
  - morelisp 6y ago
    Putting aside question of if can have responsibility for freely-released work (especially when one has made a big deal of money offered in exchange for this kind of finding), at the time this bug was discovered the software was emphatically not in the public domain and difficult to distribute modified versions of despite available source.
  - loup-vaillant 6y ago
    When you release software for the world to use, tell everyone it's secure, even put up a bug bounty… that kinda means you are taking responsibility.
sneak 6y ago
https://twitter.com/FiloSottile/status/1262854396934791168 https://twitter.com/FiloSottile/status/1262854396934791168
- dependenttypes 6y ago
  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 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 https://nacl.cr.yp.to/valid.html) In addition both Filo and Garrett have a bone to pick with DJB due to their personal political beliefs and his involvement in the Appelbaum case and I found both of them to be extremely dislikeable and unable to accept their own faults in personal discussions that I had with them in the past (regarding different issues). Considering that this was a subpost my opinion of them is even lower now.
  - sneak 6y ago
    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.
    - dependenttypes 6y ago
      (regarding qmail) It was a security bug back in 2005. It stopped being a security bug when DJB mentioned on the official page about the memory limits. 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 https://news.ycombinator.com/item?id=23250748 I think that https://old.reddit.com/r/crypto/comments/72w42c/statement_regarding_cryptanalysis_of_22_12_rounds/dnlv59e/ https://old.reddit.com/r/crypto/comments/72w42c/statement_re... would be a better example of DJB not properly handling security reports.
deleted 6y ago
[deleted]

It's not "they", it's Daniel J. Bernstein. That's the reason :) (If you don't know: he is a top cryptographer that can amazingly correct code. However, he also has a very big ego...)

DominoTree 6y ago

I just found this on Wikipedia where he raised his bug bounty and at the same time cited these "unexploitable" bugs https://en.wikipedia.org/wiki/Qmail#Security_reward_and_Georgi_Guninski's_vulnerability https://en.wikipedia.org/wiki/Qmail#Security_reward_and_Geor...

stevekemp 6y ago

qmail was essentially unmaintained for a long time, people were distributing patches to it, but there were no upstream releases. (Similar story with djbdns/tinydns.) "Recently" he released his code with new licenses, so that people could finally start distributing updated versions, rather than the previous approach where lots of people were sharing conflicting patches for various features (e.g. IPv6 support for AAAA records in tinydns.)

rurban 6y ago
notqmail.org is for long the defacto maintained version. They had this fixed long time ago.

koheripbal 6y ago

I don't understand. Most people with a big ego would not want a critical vulnerability associated with them. Can you elaborate?

loeg 6y ago
His ego has transcended objective reality and he claimed (in 2005, and continues to claim in 2020) it isn't a vulnerability.
kbenson 6y ago
he had such confidence in his software and abilities that he thought it was actually secure, and there were no bugs, and posted a bounty for any exploit that could be found. Patching it means acknowledging it's an exploit, and that his code was not without bugs. Given that his principles of writing secure software (included in the Qmail guarantee[1]) includes this: "7. Write bug-free code." that might be a bit hard for him to swallow. 1: https://cr.yp.to/qmail/guarantee.html https://cr.yp.to/qmail/guarantee.html
- rurban 6y ago
  Well, he used it with memory limits command line switches, so it could never be exploited. So he was technically correct. One should not use so much memory for a mail server, way too risky. Problem is, these switches were not default, people didnt use it because they are dumb, and DJB never cared to properly maintain it. like limiting memory per default, 32bit only builds or such.
  - kbenson 6y ago
    > Problem is, these switches were not default, people didnt use it because they are dumb Pushing complexity from a very small group (in this case, one person) who knows the system intimately to many orders of magnitude more people that are meant to have a functional knowledge of how it operates but not necessarily be intimate with it is a losing proposition, and not any tenet of how I would consider developing secure software. If the software is only supposed to be run under process limits, and over a specific process limit all bets are off security wise, then the program should probably check and report problems with large process limits when it starts. Or, as you posit, dying if built for 64 bit, since its assumptions don't necessarily hold.
  - kelnos 6y ago
    My opinion on this is that if you're going to claim that you write the most secure software in the world, it should be secure by default. It shouldn't require you to modify the configuration in a particular way, or start it in a particular way, in order to be secure. The more details you need to know in order to secure something, more less likely you'll tick off all those boxes. To me, this is just DJB's ego not allowing him to admit that he made mistakes.
mcguire 6y ago
He asserted that it was unexploitable, and thus not a vulnerability. Fixing the code would have implied that it might have been a vulnerability, and he might have been wrong. Can't have that.

vinay_ys 6y ago

http://cr.yp.to/talks/2007.11.02/slides.pdf http://cr.yp.to/talks/2007.11.02/slides.pdf I don't see ego in these slides. I see a brilliant programmer acknowledging his mistakes and learning from them. I really enjoyed running qmail in early 2000s and following djb's crypto work later. He is brilliant indeed.

cadence- 6y ago
You should read some of his public.... ekhm... “discussions” with Wietse Venema on various security forums in the 90’s. It was very entertaining, but also clearly showcasing djb’s huge ego.
- reaperducer 6y ago
  A lot of it would get you banned from HN and similar fora today.
cadence- 6y ago
Here is my favourite that I remember to this day: https://seclists.org/bugtraq/1998/Nov/117 https://seclists.org/bugtraq/1998/Nov/117
- Snelius 6y ago
  Hah, "How many people relaxed after installing tcpd -DPARANOID, instead of pestering their vendors for a real fix?" Sounds similar here ;)
  - Quekid5 6y ago
    Yeah, the lack of self-reflection is pretty palpable.

kelnos 6y ago

The funny thing about that is I find his code to be very difficult to read (even just the snippets in the linked CVE illustrate this). And his attitude is just bonkers to me. "I'm not going to fix this exploitable security issue because I assume that people will configure their environment in a particular way." What? That's... flat-out irresponsible.

dependenttypes 6y ago
He does not have any responsibility against anyone. He released his software in public domain with the source included for free.
- morelisp 6y ago
  Putting aside question of if can have responsibility for freely-released work (especially when one has made a big deal of money offered in exchange for this kind of finding), at the time this bug was discovered the software was emphatically not in the public domain and difficult to distribute modified versions of despite available source.
- loup-vaillant 6y ago
  When you release software for the world to use, tell everyone it's secure, even put up a bug bounty… that kinda means you are taking responsibility.

sneak 6y ago

https://twitter.com/FiloSottile/status/1262854396934791168 https://twitter.com/FiloSottile/status/1262854396934791168

dependenttypes 6y ago
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 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 https://nacl.cr.yp.to/valid.html) In addition both Filo and Garrett have a bone to pick with DJB due to their personal political beliefs and his involvement in the Appelbaum case and I found both of them to be extremely dislikeable and unable to accept their own faults in personal discussions that I had with them in the past (regarding different issues). Considering that this was a subpost my opinion of them is even lower now.
- sneak 6y ago
  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.
  - dependenttypes 6y ago
    (regarding qmail) It was a security bug back in 2005. It stopped being a security bug when DJB mentioned on the official page about the memory limits. 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 https://news.ycombinator.com/item?id=23250748 I think that https://old.reddit.com/r/crypto/comments/72w42c/statement_regarding_cryptanalysis_of_22_12_rounds/dnlv59e/ https://old.reddit.com/r/crypto/comments/72w42c/statement_re... would be a better example of DJB not properly handling security reports.

deleted 6y ago

[deleted]