4 ms·

> As for your final paragraph about word choice: I'm not sure what you mean, I'm just talking about any software that is running somewhere and accessible across

> As for your final paragraph about word choice: I'm not sure what you mean, I'm just talking about any software that is running somewhere and accessible across a network. Well, a web browser is accessible across a network. An email client is accessible across a network. What fundamentally distinguishes a mail server from either of those that justifies rejecting to run one of those yourself outright, while presumably being fine with the others? You seem to have some implicit assumption that a piece of software that opens a listening TCP socket is somehow much more vulnerable than one that doesn't. I don't think that that is justified, and if anything, gives you a false sense of security. > but I'm getting the sense that if I did that, you would just be dismissive of all those things as "not a big concern", "because of complexity", "because of C", etc., and I would be wasting my time. I am not dismissing anything, I am just pointing out why those aren't problems. If you disagree, feel free to disagree. And maybe make an actual more specific argument than "there are a lot of things one can do wrong". I mean, how is it relevant that there are tons of ways to screw up buffer handling in C when the obvious solution is to just not write your own personal mail server in C? Yes, it is hard to write secure software in C. Very hard. Yes, there are cases where there are good reasons to write network software in C despite that. Is your own personal mail server one of them? No. Or how is it relevant that the web is a hugely complex mess of inherently insecure APIs when the task at hand is writing an email server? Just don't write your email server as a web application and you don't have to deal with any of the myriads of security problems that plague the web. > There are plenty of places you can go read about this stuff if you want to, but I don't think you do, I think you're just looking for an argument. Good luck to you! Thanks, but I think I have found enough vulnerabilities to not need any introductory books to understand how people constantly screw up security in their code.

sanderjd 10y ago
Lookit, this thread started because you said "nor is it that hard to even write your own secure mail server, alone", which I disagreed with, saying that it is in fact "very hard". You seem to have a definition of the word "hard" that is just much closer to "infeasible" than my own, which is nearby "takes a good deal of expertise and / or effort". It really isn't very interesting which of us is more "right" about what is and isn't "hard". I honestly hope you're right that someday I'll work on a project and find myself thinking "wow, it wasn't even that hard to get the security story right on this", and I guess that day has already come for you, but it certainly hasn't for me.
- zAy0LfpBZLC8mAC 10y ago
  > You seem to have a definition of the word "hard" that is just much closer to "infeasible" than my own, which is nearby "takes a good deal of expertise and / or effort". Well, maybe. But I don't really think it takes all that much expertise. Maybe it does, in the sense that there are so many tools out there that you in principle could use to try and build an email server, and without any expertise, it might be hard to tell which tools to use, and, more importantly, which ones to avoid. So, without expertise, you might end up stuck in the local minimum that is C, say, which in turn then requires a lot of expertise and effort to build something secure, because there are just to many pitfalls to be constantly aware of if you want to pull it off. But if you manage to avoid that local minimum and use a memory-safe language with garbage collection, suddenly, avoiding buffer overflow exploits is trivial. You don't even need to understand what a buffer overflow is and why/how it can be exploited. They simply don't happen, without any detailed expertise needed. The thing is that you very well might end up writing your email server in a memory-safe language by accident. Writing a secure email server in C by accident, though? Extremely unlikely. Also, many possible security problems that plague software simply don't apply to email servers. The web is a mess and difficult to build something secure for. But email servers don't have to deal with the web, so you cannot even accidentally stumble into those problems when you are writing an email server.
  - sanderjd 10y ago
    > But I don't really think it takes all that much expertise. I think you may be living in a bubble. Building any working software takes a lot of expertise. Maybe you just mean "expertise in addition to that necessary to build any working software". In which case, maybe I don't disagree with you so much. But again, we're just debating the definitions of words like "hard" and "expertise"! There are more security issues to be concerned about than buffer overflow. Just as an example, your email server needs authentication and authorization, which are also tricky to get right. There are plenty of logic-level security issues like that for which just choosing a memory-safe language is not a solution.

sanderjd 10y ago

Lookit, this thread started because you said "nor is it that hard to even write your own secure mail server, alone", which I disagreed with, saying that it is in fact "very hard". You seem to have a definition of the word "hard" that is just much closer to "infeasible" than my own, which is nearby "takes a good deal of expertise and / or effort". It really isn't very interesting which of us is more "right" about what is and isn't "hard". I honestly hope you're right that someday I'll work on a project and find myself thinking "wow, it wasn't even that hard to get the security story right on this", and I guess that day has already come for you, but it certainly hasn't for me.

zAy0LfpBZLC8mAC 10y ago
> You seem to have a definition of the word "hard" that is just much closer to "infeasible" than my own, which is nearby "takes a good deal of expertise and / or effort". Well, maybe. But I don't really think it takes all that much expertise. Maybe it does, in the sense that there are so many tools out there that you in principle could use to try and build an email server, and without any expertise, it might be hard to tell which tools to use, and, more importantly, which ones to avoid. So, without expertise, you might end up stuck in the local minimum that is C, say, which in turn then requires a lot of expertise and effort to build something secure, because there are just to many pitfalls to be constantly aware of if you want to pull it off. But if you manage to avoid that local minimum and use a memory-safe language with garbage collection, suddenly, avoiding buffer overflow exploits is trivial. You don't even need to understand what a buffer overflow is and why/how it can be exploited. They simply don't happen, without any detailed expertise needed. The thing is that you very well might end up writing your email server in a memory-safe language by accident. Writing a secure email server in C by accident, though? Extremely unlikely. Also, many possible security problems that plague software simply don't apply to email servers. The web is a mess and difficult to build something secure for. But email servers don't have to deal with the web, so you cannot even accidentally stumble into those problems when you are writing an email server.
- sanderjd 10y ago
  > But I don't really think it takes all that much expertise. I think you may be living in a bubble. Building any working software takes a lot of expertise. Maybe you just mean "expertise in addition to that necessary to build any working software". In which case, maybe I don't disagree with you so much. But again, we're just debating the definitions of words like "hard" and "expertise"! There are more security issues to be concerned about than buffer overflow. Just as an example, your email server needs authentication and authorization, which are also tricky to get right. There are plenty of logic-level security issues like that for which just choosing a memory-safe language is not a solution.