[kbenson]

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

[dependenttypes]

He did reward some other bounties that he made, I can only think the ones from his cryptographic algorithms at the moment though.

Edit: See https://news.ycombinator.com/item?id=23250748

[rurban]

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.

[Chlorus]

> One should not use so much memory for a mail server, way too risky.

Is there a table or formula I can consult that will give this particular dumb person(myself) a handy guide for what amounts of addressable memory will introduce security risks for particular applications? Apparently more than 32-bits is obviously[0] a problem for email; what about databases? Should I feel bad I use more than 64GB of memory in my DB installations? Am I being irresponsible? What about web servers? How much risk does each additional bit of memory add?

My final question is, why does pretty much every other software maintainer not have a problem fixing the memory allocation themselves, obviating the need for external tools to fix these issues? I guess they're going the extra mile!

[0] So obvious a problem that sendmail, postfix, and exim don't require me to apply workarounds for it for some reason. Very irresponsible of them, if you ask me.

[kbenson]

> 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]

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.