
NTPsec is not quite a full rewrite - wtbob
http://esr.ibiblio.org/?p=6881
======
tptacek

        * strcpy, strncpy, strcat:  Use strlcpy and strlcat instead.
        * sprintf, vsprintf: use snprintf and vsnprintf instead.
        * In scanf and friends, the %s format without length limit is banned.
        * strtok: use strtok_r() or unroll this into the obvious loop.
        * gets: Use fgets instead. 
        * gmtime(), localtime(), asctime(), ctime(): use the reentrant *_r variants.
        * tmpnam() - use mkstemp() or tmpfile() instead.
        * dirname() - the Linux version is re-entrant but this property is not portable.
    

And so, instead of competent systems code of 1995 vintage, we get ESR code of
1998 vintage.

Presumably, someone else, somewhere else, is solving the problem that needs to
be solved, which is to get an NTP implementation that is simple but complete
enough for the 98% use case deployed based either on thoroughly modern C code
(which looks nothing like a heap of strlcats and snprintfs) or a safer
language, like Rust or Go.

Maybe that's ntimed, maybe it's something else. It's not this, whatever the
hell this is going to turn out to be.

~~~
jabl
So, were I to seek examples of such "thoroughly modern C code" in order to
educate myself, do you have some suggestions where to look?

In particular, would you recommend to do string handling with some string
library (e.g. glib has one?), or just use the mem*() functions and manually
keep track of the lengths, or what?

~~~
tptacek
Check out the recent AGL story on BoringSSL for an idea of what a conversion
from 90s C code to modern C code looks like.

Yes: do string handling with high-level string abstractions. No, don't try to
freelance it with the mem-() functions.

------
dmit
Interesting, this and phk's ntimed are both sponsored by the Linux Foundation.
I guess it makes sense on some level to have concurrent projects that tackle
the same problem from different directions.

~~~
hga
Here's ESR's comment on ntimed
([http://esr.ibiblio.org/?p=6863&cpage=1#comment-1635375](http://esr.ibiblio.org/?p=6863&cpage=1#comment-1635375)):

 _esr on 2015-10-09 at 09:22:05 said:

>Eric, what do you think of ntimed and their goal of replacing ntpd?

PHK is a bright guy with many clues. I respect him a lot, and I say this
despite the fact that he’s hostile to me because he thinks my open-source
advocacy has encouraged crappy programming. I have not looked closely at
ntimed but I have little doubt it is high-quality work, probably as good as
anything I am capable of producing, possibly better.

That said, I think ntimed is going nowhere. A clean-sheet design was the right
thing from a technical point of view, but it’s not what the time-service
userbase wants. Large time-service users are intensely conservative and risk-
averse; what they want, and what NTPsec will deliver, is not radical
innovation but a cleaned-up and hardened version of what they know._

The only active GitHub ntimed fork is for the Amiga/AROS version, and phk's
GitHub visible work as of late seems to be mostly on Varnish Cache.

~~~
dmit
_> > I have not looked closely at ntimed but I have little doubt it is high-
quality work, probably as good as anything I am capable of producing, possibly
better._

Ok, that is just precious. =) One is a kernel hacker and time-nuts regular
with one of the world's most precise clocks in his home, and the other
recently wrote:

 _> There’s a longstanding legend that only Dave Mills ever really understood
the Byzantine time-synchronization algorithms at NTP’s heart, but I used to be
a mathematician and I think I already get most of it outside of a few arcana
about statistical filtering of noisy signals._

From a purely technical standpoint, I know who I'd bet my money on.

By the way, phk recently mentioned that he was getting back into ntimed, so
fingers crossed that we get two safe and correct NTP alternatives in the
observable future.

[https://twitter.com/allanjude/status/635635386832715777](https://twitter.com/allanjude/status/635635386832715777)

~~~
hga
While he said as of August 23rd that he's agin working on ntimed, that's not
reflected in GitHub updates:
[https://github.com/bsdphk/Ntimed](https://github.com/bsdphk/Ntimed)

And it bears mentioning that ESR has been working on GPSD for more than a
decade (a daemon to extract accurate time from GPS receivers), and he sure
_sounds_ math literate to my not entirely untutored ears in various
discussions over the years.

Given the well known curse of total rewrites, which I've experienced myself, I
too know who I'd bet my money on.

~~~
gonzo
> "he sure sounds math literate"

This is the standard ESR parlor trick. Eric took several courses in math and
philosophy at the University of Pennsylvania.

[http://poynder.blogspot.com/2006/03/interview-with-eric-
raym...](http://poynder.blogspot.com/2006/03/interview-with-eric-raymond.html)
"As a freshman at the University of Pennsylvania Raymond was immediately
marked out as a potential math prodigy. Having found school insufficiently
stretching for his above average talents, however, he lacked the necessary
discipline or emotional maturity to cope with the demands of an undergraduate
course, and after suffering a "math burnout" left without a degree."

I'd put my money on phk. Every. Time.

------
scaramanga
Hilarious reading, of course, "I do have an an advantage because I’m very
bright"

------
technion
There's at least one thing ESR and phk agree on - the autoconf situation.

I'm looking at the list of tests done in current ntpd.

* Checking whether compiler accepts -g * Checking whether compiler supports C89 * Checking if stdlib.h exists * Check if compiler supports -o * Hunts for just about every command line tool, sed, awk, ln, grep * Is size_t a type?

There are dozens of checks that could be replaced with "Checking for OS =
Windows".

There are specific code paths for Digital Unix 4.0, a fix specific to AIX 4.3
with the comment "hopefully adding ... fixing this without breaking any other
platform", Ultrix, winnt3.5?,

How many NTP developers routinely test new code against all these platforms?

However it's done, more big name programs need to move on from this.

------
hannob
One thing that I find a bit worrying is that there are now two projects that
try to create better implementations of the existing ntp protocol, but the
protocol itself is inherently insecure. ntp right now is a clear-text protocol
with no authentication and no protection at all against man-in-the-middle-
attacks. There are two authentication modes from which one is insecure and the
other relies on symmetric keys, which is impractical.

There's some work done on ntp security [1], I hope we'll see this implemented
soon.

[1] [https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-
ntp](https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp)

~~~
dfc
I am assuming that when you refer to "the other project trying to create a
better implementation" you are referring to ntimed? It seems that you are
forgetting about Chrony and OpenNTPd.

------
nickpsecurity
A real-time guard can handle most of what it needs: packet-inspection, rate
limiting, spotting NTP layer abuse, transport security, authentication, small
TCB, real-time, etc. Highly-assured guards have been used for about every
other insecure app and protocol so I don't see why not this one.

Throw in tech like Code Pointer Integrity or Softbound on client side for
extra measure. Or reimplement it in an inherently safer language.

