And it very probably has zero memory safety bugs (pretty easy in 4,000 lines of code, as measured in a tarball I just downloaded), and privsep provides further defense at the cost of adding a lot of complication to the code... but I'm getting bored of this approach to security. For new code - I know openntpd is not new code, but I don't think this approach is popular in general yet - why not switch to Go or (when it's stable) Rust, or even JavaScript or Lua, and end up with essentially zero chance of such bugs being possible, regardless of how carefully or not the code was written, without the need for any privilege separation code? For something like NTP or SSH or most of the other daemons written in C people have sitting around, with the possible exception of high performance HTTP servers, the CPU overhead of any those languages is very unlikely to be noticeable (and privsep has overhead anyway).

(Admittedly, this would not help with non-memory-safety attacks such as NTP amplification...)

In particular, I'm going to make a bold claim: for OpenBSD to continue to release new daemons written in C, as it does, is irresponsible for a security-focused distribution. As much as they like the language - I do too -, as much as the whole expertise and design of the project is based on C, such that there is a naturally huge disincentive to switch languages, and as much as OpenBSD is able to minimize (but not eliminate) security advisories of this type, memory corruption is so dangerous that building a truly secure system requires making as much code as possible immune to the possibility of it.

(Hmm, I guess running AddressSanitizer in production would be nearly as good.)