[groks]

> The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn't been.

They talk about 3 areas where bugs have been removed, including:

  Much of ntpd’s most convoluted code lives in ntp_proto.c, which
  implements the state machine central to the protocol. Of the 29
  vulnerabilities that have received CVEs so far in 2016, a couple
  of multi-KLOC functions in ntp_proto.c are responsible for 15 of
  them — just over half. Of course, "just rip it out" wouldn’t
  suffice in this case: this is core business logic, not junk code.
  So we rewrote those functions from scratch, cutting line count
  considerably and yielding a far more readable result.

https://blog.ntpsec.org/2016/12/13/fantastic-bugs-and-where-...

The other two areas are guaranteed bug-free because they removed the code.

[tptacek]

From this paragraph you might get the impression that ntpsec had dodged 29 CVEs in 2016. But that's not the impression I have: I think it has been vulnerable to many of the bugs reported in ntpd.

Further: not all CVEs are equivalent, so in addition to wanting to know how many vulnerabilities ntpsec was also vulnerable to, you also want to know what the distribution both of severity and of exposure in the default configuration those bugs had.

Ultimately: I feel about ntpsec the way I would have felt if, in 1997, someone had proposed SendmailSec. The answer to the Sendmail security problem wasn't a "hardened" Sendmail (though the Sendmail team sure tried); it was Postfix and qmail.