6 ms·

That's a fantastic endorsement for Dovecot. It's interesting that security is not highlighted on the homepage[0], just mentioned in passing. Also interesting is

by tln 10y ago

That's a fantastic endorsement for Dovecot. It's interesting that security is not highlighted on the homepage[0], just mentioned in passing. Also interesting is the "special C variant that makes it much more difficult to write security holes"[1] [0]: https://www.dovecot.org https://www.dovecot.org [1]: https://www.dovecot.org/security.html https://www.dovecot.org/security.html

rubyn00bie 10y ago
I was curious about what this special variant entailed and it looks to be some sensible guidelines/practices: https://github.com/dovecot/core/blob/master/doc/securecoding.txt https://github.com/dovecot/core/blob/master/doc/securecoding...
- rtpg 10y ago
  >Don't rely on input validation. Maybe you missed something. Maybe someone calls your function somewhere else where you didn't originally intend it. Maybe someone makes the input validation less restrictive for some reason. Point is, it's not an excuse to cause a security hole just because input wasn't what you expected it to be. This point makes me mad because we have both ways to statically verify that calling conditions are "correct" through the right kind of design, and it should be a zero-cost abstraction but you can't do it in C. Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding. Issues that don't exist if you could set up "proper" type checking in C without having to use things like wrapper structs that incur performance penalties. Defensive programming is always a bit weird because it always feels un-necessary, but in C it's really necessary because you have so few assurances. Pretty scary I wonder if there's a tool out there that lets you use Rust-style linear types over C code, and other things that would make some of this advice redundant (because the CI server would check the code). You could still write C, but wrong C would error in the checking step.
  - viraptor 10y ago
    I don't think they meant what you described here. > Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding. That's escaping - it's not the same as validation. What they mean is that you shouldn't expect that the invariants you see right now to hold in the future. It still means that you should only escape right before the data sink that requires it. But on the other hand it means: escape it right before the data sink, even if you see that the caller only passes in 2 different static strings - it may change. Or escape even if the current filter before rejects anything apart from digits.
    - rtpg 10y ago
      Their advice seems to be "do not assume invariants on inputs". In which case you can only assume that your input is unescaped, right? If you could assume escaping, that means you're limiting your input, which seems to go against the advice from my reading. I gave escaping as an example, but one of the primary ways to reduce bugs is to reduce the scope of possible inputs as much as possible (thus reducing the scope of output to manage). The requirements are different depending on the use case, but for application-internal code, not relying on that means that so much more global knowledge about the project is necessary to work on it. And, of course, a greater possibility of mistakes (because your requirements are more vast)
- duneroadrunner 10y ago
  > it looks to be some sensible guidelines/practices But more notably I think, a whole bunch of custom functions and data types to be used in place of more typical C coding practices. The document references a number of (presumably custom) header files (lib/buffer.h, lib/str.h, lib/strfuncs.h, lib/array.h, lib/data-stack.h, lib/mempool.h), the Boehm GC, and use of "GCC Extensions". Also, there seems to be one person contributing an overwhelming proportion of commits (just going by the "contributors" page). Hmm, this seems to be an example of largely a single person implementing a program in C with a priority on code safety. Impressively successfully. But with substantial effort and individual discipline employed to avoid the pitfalls of C. I'm not sure how scalable/transferable this kind of approach is. Perhaps the takeaway here is i) This is an impressive (mostly) individual achievement. ii) Dovecot may have some useful libraries for improving code safety if you're forced to or are committed to using C. iii) The effort and discipline required to achieve code safety in C in this case, might also be interpreted as a validation of the effort and time required to achieve code safety by adopting newer alternatives like Rust and SaferCPlusPlus[1] when those choices are available. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
inopinatus 10y ago
If you hack on the source (as I have for both fun and profit) then the secure coding style and defensive internal infrastructure quickly become obvious and natural to work with. It's a great product, inside & out.
sandGorgon 10y ago
is this is a good usecase for building this in Rust instead ?
- vetinari 10y ago
  There's currently going a discussion, whether Rust is ready yet for such a project. See http://esr.ibiblio.org/?p=7303 http://esr.ibiblio.org/?p=7303
  - uiri 10y ago
    ESR claims: But you guys have competition out there: Go, Nim, Swift, D, and maybe other languages that aren’t on anyone’s radar yet. All those languages are garbage collected or use automatic reference counting. Rust is unique in using its type system to automatically allocate and free memory. For the use cases where the overhead of GC is too high - Wich are the same use cases that generally call for C or C++ these days - Rust has no competition. I think this explains why Rust is still in the explore phase.
    - nickpsecurity 10y ago
      That claim gets even stronger if one considers real-time GC's or ref counting. Like how they do with Java for embedded systems. The places where Rust is uniquely advantageous gets smaller.
    - noselasd 10y ago
      Having a garbage collector is no showstopper for writing an email server though.
  - msbarnett 10y ago
    "Discussion" isn't the word I'd use to describe that mess. Criticizing a low-level language that makes it cheap and easy to directly call C APIs directly for not providing special syntax for select/kqueue/epoll when he could just call epoll if that's what he wants makes it clear that he wants to be writing some other, higher level language entirely. It tells us nothing interesting about whether or not Dovecot, a project that wants low-level direct binding to POSIX APIs, is not suited for Rust.
diggan 10y ago
I think including security in the first paragraph you read can be called a highlight. First sentence: "Dovecot is an open source IMAP and POP3 email server for Linux/UNIX-like systems, written with security primarily in mind"
- gkya 10y ago
  It actually says "secure imap server" besides the logo in the page header too.

by tln 10y ago

rubyn00bie 10y ago

I was curious about what this special variant entailed and it looks to be some sensible guidelines/practices: https://github.com/dovecot/core/blob/master/doc/securecoding.txt https://github.com/dovecot/core/blob/master/doc/securecoding...

rtpg 10y ago
>Don't rely on input validation. Maybe you missed something. Maybe someone calls your function somewhere else where you didn't originally intend it. Maybe someone makes the input validation less restrictive for some reason. Point is, it's not an excuse to cause a security hole just because input wasn't what you expected it to be. This point makes me mad because we have both ways to statically verify that calling conditions are "correct" through the right kind of design, and it should be a zero-cost abstraction but you can't do it in C. Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding. Issues that don't exist if you could set up "proper" type checking in C without having to use things like wrapper structs that incur performance penalties. Defensive programming is always a bit weird because it always feels un-necessary, but in C it's really necessary because you have so few assurances. Pretty scary I wonder if there's a tool out there that lets you use Rust-style linear types over C code, and other things that would make some of this advice redundant (because the CI server would check the code). You could still write C, but wrong C would error in the checking step.
- viraptor 10y ago
  I don't think they meant what you described here. > Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding. That's escaping - it's not the same as validation. What they mean is that you shouldn't expect that the invariants you see right now to hold in the future. It still means that you should only escape right before the data sink that requires it. But on the other hand it means: escape it right before the data sink, even if you see that the caller only passes in 2 different static strings - it may change. Or escape even if the current filter before rejects anything apart from digits.
  - rtpg 10y ago
    Their advice seems to be "do not assume invariants on inputs". In which case you can only assume that your input is unescaped, right? If you could assume escaping, that means you're limiting your input, which seems to go against the advice from my reading. I gave escaping as an example, but one of the primary ways to reduce bugs is to reduce the scope of possible inputs as much as possible (thus reducing the scope of output to manage). The requirements are different depending on the use case, but for application-internal code, not relying on that means that so much more global knowledge about the project is necessary to work on it. And, of course, a greater possibility of mistakes (because your requirements are more vast)
duneroadrunner 10y ago
> it looks to be some sensible guidelines/practices But more notably I think, a whole bunch of custom functions and data types to be used in place of more typical C coding practices. The document references a number of (presumably custom) header files (lib/buffer.h, lib/str.h, lib/strfuncs.h, lib/array.h, lib/data-stack.h, lib/mempool.h), the Boehm GC, and use of "GCC Extensions". Also, there seems to be one person contributing an overwhelming proportion of commits (just going by the "contributors" page). Hmm, this seems to be an example of largely a single person implementing a program in C with a priority on code safety. Impressively successfully. But with substantial effort and individual discipline employed to avoid the pitfalls of C. I'm not sure how scalable/transferable this kind of approach is. Perhaps the takeaway here is i) This is an impressive (mostly) individual achievement. ii) Dovecot may have some useful libraries for improving code safety if you're forced to or are committed to using C. iii) The effort and discipline required to achieve code safety in C in this case, might also be interpreted as a validation of the effort and time required to achieve code safety by adopting newer alternatives like Rust and SaferCPlusPlus[1] when those choices are available. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

inopinatus 10y ago

If you hack on the source (as I have for both fun and profit) then the secure coding style and defensive internal infrastructure quickly become obvious and natural to work with. It's a great product, inside & out.

sandGorgon 10y ago

is this is a good usecase for building this in Rust instead ?

vetinari 10y ago
There's currently going a discussion, whether Rust is ready yet for such a project. See http://esr.ibiblio.org/?p=7303 http://esr.ibiblio.org/?p=7303
- uiri 10y ago
  ESR claims: But you guys have competition out there: Go, Nim, Swift, D, and maybe other languages that aren’t on anyone’s radar yet. All those languages are garbage collected or use automatic reference counting. Rust is unique in using its type system to automatically allocate and free memory. For the use cases where the overhead of GC is too high - Wich are the same use cases that generally call for C or C++ these days - Rust has no competition. I think this explains why Rust is still in the explore phase.
  - nickpsecurity 10y ago
    That claim gets even stronger if one considers real-time GC's or ref counting. Like how they do with Java for embedded systems. The places where Rust is uniquely advantageous gets smaller.
  - noselasd 10y ago
    Having a garbage collector is no showstopper for writing an email server though.
- msbarnett 10y ago
  "Discussion" isn't the word I'd use to describe that mess. Criticizing a low-level language that makes it cheap and easy to directly call C APIs directly for not providing special syntax for select/kqueue/epoll when he could just call epoll if that's what he wants makes it clear that he wants to be writing some other, higher level language entirely. It tells us nothing interesting about whether or not Dovecot, a project that wants low-level direct binding to POSIX APIs, is not suited for Rust.

diggan 10y ago

I think including security in the first paragraph you read can be called a highlight. First sentence: "Dovecot is an open source IMAP and POP3 email server for Linux/UNIX-like systems, written with security primarily in mind"

gkya 10y ago
It actually says "secure imap server" besides the logo in the page header too.