Re:Dovecot audit complete
by frederikvs on Monday January 16, 2017 @04:29AM
(#13409011)
Makes one wonder how they achieved this. I can find a passing mention of a "special C variant that makes it much more difficult to write security holes"[0], but no more details on whether they enforce this (and how), nor on other techniques to improve security.
Do they have a rules checker? Are they running static analysis? Which security-related compiler flags are they enabling? Other tools they use to achieve this?
Or is it just a lead developer who really groks C and security, and who reviews all PRs?
It'd be interesting to see what that other projects can learn here to improve security...
Re:Dovecot audit complete
by gcp on Monday January 16, 2017 @04:52AM
(#13409094)
Much like djb's code it's forcing the most error prone parts (string handling, memory) to go through a library, or simply forbidding the error prone constructs entirely (static buffers).
Do they have a rules checker? Are they running static analysis? Which security-related compiler flags are they enabling? Other tools they use to achieve this? Or is it just a lead developer who really groks C and security, and who reviews all PRs?
It'd be interesting to see what that other projects can learn here to improve security...
[0] https://www.dovecot.org/security.html