4 ms·

I continue to be surprised by the sheer amount of writing we see about ntpsec. The project was started over two years ago, and yet progress reports seem very o

I continue to be surprised by the sheer amount of writing we see about ntpsec. The project was started over two years ago, and yet progress reports seem very optimistic and self-congratulatory, despite an obvious lack of progress. Sure rewriting "bits" of things, with more features, and adding my python sounds useful. But here we are 500+ days since the project started and there are only minor experiments in moving from C. I get the feeling this is one of those projects which will never be complete. Perhaps not a bad thing, providing those involved are having fun, but so much verbiage to say so.

tptacek 10y ago
Moreover, at the point where you're rewriting ntpd in a new language, you're no longer really producing a hardened version of the original. There already are competing ntpd implementations, if that's all you're after, so this latest excursion into Rust and Go raises the question of whether the project still even makes sense.
bluejekyll 10y ago
I had the same thought. I will say that that lack of progress may be the exact reason why so much consideration is being put into porting to another language, so as to make faster progress.
rev_null 10y ago
To be fair, this was written by ESR. His code to self-congratulatory ratio was pretty high to begin with.
- skj 10y ago
  I assume you mean low? :)
nimish 10y ago
This is basically Eric S Raymond's modus operandi. Instead of bikeshedding over Go vs Rust he could have had an MVP up by now
- problems 10y ago
  He does, there are releases for NTPsec in C. He's just recently debating about Go vs Rust as a possible transition.
jerf 10y ago
What progress are you looking for? There seem to be downloads here, posted pretty regularly: ftp://ftp.ntpsec.org/pub/releases/ I don't know if they build and work, but I'd suspect they do, based on the refactorings being discussed. The commits seem to be clicking along. A diffstat of roughly where I think they branched off of ntp vs. master takes a moment to poke through, because the raw stats are "1032 files changed, 126489 insertions(+), 143789 deletions(-)", but there's a lot of trading C code for test code and more docs in there. I don't know exactly what metric you're using but this doesn't match my "obvious lack of progress".
- tptacek 10y ago
  They started with Mills ntpd, so there have been downloads available since t0. There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either. 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. At the point where they rewrite in a new language, they're embarking on a fundamentally different project with a different value proposition, which sort of moots the progress they've made (or not made) on hardening ntpd. (Fair warning: I am both an ESR skeptic and an ntpsec skeptic; I genuinely do not like the idea behind the ntpsec project).
  - wtbob 10y ago
    > There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either. Can't 'ifdefs that nobody uses' hide security flaws? Removing them helps the overall security of the codebase, preventing folks from accidentally enabling a long-dormant codepath, no? > 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. True enough. Are there any numbers on that?
    - tptacek 10y ago
SEJeff 10y ago
ESR is a master of just this. He's involved, just ask him :) http://esr.ibiblio.org/?p=6820 http://esr.ibiblio.org/?p=6820
NelsonMinar 10y ago
I've been pondering this question too. NTP is a very important Internet service and it's great that folks are looking for a more secure alternative to traditional ntpd. I'm not sure if NTPsec is going to get there or not. The best alternative out there right now seems to be Chrony. But it hasn't had nearly the inspection and usage ntpd has had, so it's hard to know for sure about its security. ntimed was also looking promising but seems stalled. openntpd doesn't keep time very well and systemd-timesyncd isn't really an NTP implementation.

tptacek 10y ago

Moreover, at the point where you're rewriting ntpd in a new language, you're no longer really producing a hardened version of the original. There already are competing ntpd implementations, if that's all you're after, so this latest excursion into Rust and Go raises the question of whether the project still even makes sense.

bluejekyll 10y ago

I had the same thought. I will say that that lack of progress may be the exact reason why so much consideration is being put into porting to another language, so as to make faster progress.

rev_null 10y ago

To be fair, this was written by ESR. His code to self-congratulatory ratio was pretty high to begin with.

skj 10y ago
I assume you mean low? :)

nimish 10y ago

This is basically Eric S Raymond's modus operandi. Instead of bikeshedding over Go vs Rust he could have had an MVP up by now

problems 10y ago
He does, there are releases for NTPsec in C. He's just recently debating about Go vs Rust as a possible transition.

jerf 10y ago

What progress are you looking for? There seem to be downloads here, posted pretty regularly: ftp://ftp.ntpsec.org/pub/releases/ I don't know if they build and work, but I'd suspect they do, based on the refactorings being discussed. The commits seem to be clicking along. A diffstat of roughly where I think they branched off of ntp vs. master takes a moment to poke through, because the raw stats are "1032 files changed, 126489 insertions(+), 143789 deletions(-)", but there's a lot of trading C code for test code and more docs in there. I don't know exactly what metric you're using but this doesn't match my "obvious lack of progress".

tptacek 10y ago
They started with Mills ntpd, so there have been downloads available since t0. There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either. 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. At the point where they rewrite in a new language, they're embarking on a fundamentally different project with a different value proposition, which sort of moots the progress they've made (or not made) on hardening ntpd. (Fair warning: I am both an ESR skeptic and an ntpsec skeptic; I genuinely do not like the idea behind the ntpsec project).
- wtbob 10y ago
  > There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either. Can't 'ifdefs that nobody uses' hide security flaws? Removing them helps the overall security of the codebase, preventing folks from accidentally enabling a long-dormant codepath, no? > 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. True enough. Are there any numbers on that?
  - tptacek 10y ago

SEJeff 10y ago

ESR is a master of just this. He's involved, just ask him :) http://esr.ibiblio.org/?p=6820 http://esr.ibiblio.org/?p=6820

NelsonMinar 10y ago

I've been pondering this question too. NTP is a very important Internet service and it's great that folks are looking for a more secure alternative to traditional ntpd. I'm not sure if NTPsec is going to get there or not. The best alternative out there right now seems to be Chrony. But it hasn't had nearly the inspection and usage ntpd has had, so it's hard to know for sure about its security. ntimed was also looking promising but seems stalled. openntpd doesn't keep time very well and systemd-timesyncd isn't really an NTP implementation.