7 ms·

I guess I'll be the one to ask: Why write an email server with security as priority #1 in C? I'd understand if it was built off of an existing daemon, but it se

I guess I'll be the one to ask: Why write an email server with security as priority #1 in C? I'd understand if it was built off of an existing daemon, but it seems that this was written from scratch. There are many other options out there that are reasonably fast and don't have the pitfalls of manual memory management and undefined behavior that C has.

jhasse 9y ago
One reason for this could be that for an open-source application with focus on security it's very important to have many collaboraters, who look at your code and contribute. C is still very popular and many people know it.
- doomrobo 9y ago
  There are plenty of popular safe languages. Java, Go, and Python are all viable options here.
- tptacek 9y ago
  C limits the pool of contributors. It doesn't expand it.
  - devillius 9y ago
    I don't think the Python/Ruby/Node/VB developers are the intended contributors. Source: I'm a Python/Ruby/Node/VB/C/C++ dev
    - tptacek 9y ago
      Why not? (I started my career shipping C code, FWIW.)
  - Alupis 9y ago
    > C limits the pool of contributors. It doesn't expand it. Oh boy, I'm starting to grow weary of folks tirelessly thumping this mantra. It's patently absurd.
    - tptacek 9y ago
      Do go on.
      - Alupis 9y ago
        I do.
        tptacek 9y ago
        No, really. It sounds to me like you think the number of C developers is comparable to the number of high-level language developers. Tell me more.
        Alupis 9y ago
        The overwhelming majority of "high-level language" developers are, at an absolute minimum, familiar enough with C, or C-like languages, to be able to read/contribute to a C project. Heck, most of us, yourself included, started off with C... it's just how it was/is taught. Perhaps your C skills get rusty without use, or perhaps you're not a bit-twiddling magician, but you can still read it, and therefore think about it, and therefore write it. It doesn't limit the pool of contributors... quite the opposite. Now, if you want to have a debate about a better choice of language for other reasons, that might be fair game... but to imply there's a shortage of C developers is just absurd.
        tptacek 9y ago
        I could not disagree more strongly with this. Most of the Python and Ruby developers I know are not comfortable writing C code. More importantly, there's nothing in the world more dangerous than someone who knows just enough to get something working in C. C is a harder language to learn than Ruby, Python, or Javascript. Unlike any of those languages, to write in C you have to constantly keep object life cycles, memory hierarchy, and memory layout in mind. Most of the standard libraries of Python or Ruby --- even simple string manipulation --- are idiomatically written and rewritten by hand in C. Even experienced C programmers forget, routinely and to calamitous affect, how machine integers work. Writing something in C reduces the number of programmers who can contribute to a project. And that reduction is going to get worse and worse over time. When I started my career, if you were going to ship code to clients, C was the industry standard way to accomplish that. A giant chunk of all working programmers used C as their daily language. Today, only a small minority of programmers will ever once write a production C module.
cyphar 9y ago
The most "interesting" thing is that they decided to effectively combine all of the components of a mail server into a single binary. This is actually advertised as a feature ("packaging is hard"), which is quite worrying because having everything in one address space means a minor bug in one piece now affects the integrity of all of the server components.
elif 9y ago
Well, email is not that complicated, three letter agencies in the US have a history of hiding backdoors in technology, and one of the authors had his company destroyed by one of those agencies. If you're writing software for the tinfoil hat crowd, and you're using high level languages and existing libraries to do very basic things, you raise suspicion even if it isn't immediately justifiable... the suspicion that most major routers were routinely pwned wasn't justifiable in April, either. Speed is almost never the primary concern with email, which is a world full of rate limits, throttles, spam filters, transient failures, tarpitting, blacklisting, inbox placement delays, etc.
- doomrobo 9y ago
  >three letter agencies in the US have a history of hiding backdoors in technology So the solution is to use the simplest tech stack possible and put the vulnerabilities in there yourself? If you're using this software, you have to trust somebody. I think most people would sooner trust that Java isn't backdoored than trust that this new C project doesn't have any buffer overflows or memory leaks.
  - ladarlevison 9y ago
    I disagree. The more layers of abstraction you have, the more places there are for a backdoor to hide. Also, unless you're using OpenJDK, Java means downloading a binary blob which could be hiding any number of surprises, intentional, or accidental. With magma I've taken the approach of trying to limit my dependencies to the kernel, and libc. Anything else I use is bundled and thus gets tested extensively for leaks, overflows, etc. That doesn't mean bugs don't exist, but it does mean if they exist, then the source is there for you to inspect and fix.
  - elif 9y ago
    Different strokes for different folks. I think intentional bugs are far worse than unintended, and scanning a c project for buffer overflows is relatively trivial compared to scanning tons of libraries for flaws so obfuscated they made it through review. In my mind technical analysis is incomplete at finding 100% of intended or unintended flaws in either system, but the DIY approach allows for trust in the authors whereas a deep stack makes attribution muddy.
cbuq 9y ago
Your concern of memory management and undefined behavior is not unfounded. But in my opinion all languages have these problems, in the C the blame is shifted to the software engineer instead of the language authors.

jhasse 9y ago

One reason for this could be that for an open-source application with focus on security it's very important to have many collaboraters, who look at your code and contribute. C is still very popular and many people know it.

doomrobo 9y ago
There are plenty of popular safe languages. Java, Go, and Python are all viable options here.
tptacek 9y ago
C limits the pool of contributors. It doesn't expand it.
- devillius 9y ago
  I don't think the Python/Ruby/Node/VB developers are the intended contributors. Source: I'm a Python/Ruby/Node/VB/C/C++ dev
  - tptacek 9y ago
    Why not? (I started my career shipping C code, FWIW.)
- Alupis 9y ago
  > C limits the pool of contributors. It doesn't expand it. Oh boy, I'm starting to grow weary of folks tirelessly thumping this mantra. It's patently absurd.
  - tptacek 9y ago
    Do go on.
    - Alupis 9y ago
      I do.
      - tptacek 9y ago
        No, really. It sounds to me like you think the number of C developers is comparable to the number of high-level language developers. Tell me more.
        Alupis 9y ago
        The overwhelming majority of "high-level language" developers are, at an absolute minimum, familiar enough with C, or C-like languages, to be able to read/contribute to a C project. Heck, most of us, yourself included, started off with C... it's just how it was/is taught. Perhaps your C skills get rusty without use, or perhaps you're not a bit-twiddling magician, but you can still read it, and therefore think about it, and therefore write it. It doesn't limit the pool of contributors... quite the opposite. Now, if you want to have a debate about a better choice of language for other reasons, that might be fair game... but to imply there's a shortage of C developers is just absurd.
        tptacek 9y ago
        I could not disagree more strongly with this. Most of the Python and Ruby developers I know are not comfortable writing C code. More importantly, there's nothing in the world more dangerous than someone who knows just enough to get something working in C. C is a harder language to learn than Ruby, Python, or Javascript. Unlike any of those languages, to write in C you have to constantly keep object life cycles, memory hierarchy, and memory layout in mind. Most of the standard libraries of Python or Ruby --- even simple string manipulation --- are idiomatically written and rewritten by hand in C. Even experienced C programmers forget, routinely and to calamitous affect, how machine integers work. Writing something in C reduces the number of programmers who can contribute to a project. And that reduction is going to get worse and worse over time. When I started my career, if you were going to ship code to clients, C was the industry standard way to accomplish that. A giant chunk of all working programmers used C as their daily language. Today, only a small minority of programmers will ever once write a production C module.

cyphar 9y ago

The most "interesting" thing is that they decided to effectively combine all of the components of a mail server into a single binary. This is actually advertised as a feature ("packaging is hard"), which is quite worrying because having everything in one address space means a minor bug in one piece now affects the integrity of all of the server components.

elif 9y ago

Well, email is not that complicated, three letter agencies in the US have a history of hiding backdoors in technology, and one of the authors had his company destroyed by one of those agencies. If you're writing software for the tinfoil hat crowd, and you're using high level languages and existing libraries to do very basic things, you raise suspicion even if it isn't immediately justifiable... the suspicion that most major routers were routinely pwned wasn't justifiable in April, either. Speed is almost never the primary concern with email, which is a world full of rate limits, throttles, spam filters, transient failures, tarpitting, blacklisting, inbox placement delays, etc.

doomrobo 9y ago
>three letter agencies in the US have a history of hiding backdoors in technology So the solution is to use the simplest tech stack possible and put the vulnerabilities in there yourself? If you're using this software, you have to trust somebody. I think most people would sooner trust that Java isn't backdoored than trust that this new C project doesn't have any buffer overflows or memory leaks.
- ladarlevison 9y ago
  I disagree. The more layers of abstraction you have, the more places there are for a backdoor to hide. Also, unless you're using OpenJDK, Java means downloading a binary blob which could be hiding any number of surprises, intentional, or accidental. With magma I've taken the approach of trying to limit my dependencies to the kernel, and libc. Anything else I use is bundled and thus gets tested extensively for leaks, overflows, etc. That doesn't mean bugs don't exist, but it does mean if they exist, then the source is there for you to inspect and fix.
- elif 9y ago
  Different strokes for different folks. I think intentional bugs are far worse than unintended, and scanning a c project for buffer overflows is relatively trivial compared to scanning tons of libraries for flaws so obfuscated they made it through review. In my mind technical analysis is incomplete at finding 100% of intended or unintended flaws in either system, but the DIY approach allows for trust in the authors whereas a deep stack makes attribution muddy.

cbuq 9y ago

Your concern of memory management and undefined behavior is not unfounded. But in my opinion all languages have these problems, in the C the blame is shifted to the software engineer instead of the language authors.