NTP - big picture

[Eric S. Raymond]

Hal Murray via devel <devel at ntpsec.org>:
> 
> I think we should step back and look at the big picture.

Agreed.

> Eric started working on the bits but got sidetracked on some cleanups.

You're a bit behind because I hadn't announced it in email yet (not
enough testing until late yesterday), but that swamp is drained.  The
endianness bug is fixed and the fix has been triple-verified.  The
nts.c interface to the rest of the code is defined and the hooks for
it are in place in the protocol engine.

As a nice side effect, the mode 3 wire format is no longer visible or
referenced outside the protocol-engine module.

Config support is waiting on you guys to tell me what the grammar of
the "nts" statement ought to be.

I'm now thinking hard about ntsd.  Current discussion on the signal channel
is whether or not to make this our first foray into production Go code.

The argument for is this: I've looked at Go code for a complete TCP
echo server.  It's 65 LOC with *no ifdefs*.  There's a TLS-listener
module in the standard library, full TLS support would add another ten
lines.  Go was designed for this sort of work, it has excellent
library support. The resulting code would be *absurdly* simple to
write and maintain.

Against: increases our count of implementation languages, and would
create some minor build-system headaches at the join between waf and
the Golang builder.  If we go this route we should be moving with
all delibetare speed to turf Python out of the suite.

General remark about that: Moving all the client code out of C into Python
was a Good Thing when we did it.  But I think a fast move of that same code
from Python to Go looks both appealing and plausible now.  A major thing
that makes it appealing is that Python library management has turned into
a running sore that I want to be rid of.

(You may not know that I have written and tested a tool called pytogo that
does maybe 85% of Python to Go lifting on typical code. I qualified it on
reposurgeon. Ian estimates that with that in hand it would only take him
a week or two to get the whole job done.  I concur.)

> I think we need to think hard about how/where/when we do the byte swapping.  
> More in another message.  This isn't specific to NTS, but NTS is the first 
> time we have used extensions and they are tangled up with byte swapping.

Fair point.  I've seem your mail about this and will reply.

> There is discussion going on about the changes to ntp.conf.

Yeah, I'm actually a bit blocked on you guys coming up with a final grammar
and semantics.  The good news is that I know yacc like the back of my hand;
once you figure out what we need you'll probably get same-day service.

> The other large area I can see is TLS and certificates.  We are going to need 
> good documentation to guide a server operator through setting up certificates. 
>  (Pointers to other documentation are fine.)
> 
> We are also going to need documentation for how to setup self-signed 
> certificates for testing.  I poked around a bit but didn't find what I needed 
> before I shifted to something else.
> 
> If anybody is familiar with TLS, I think it would be wonderful if we had some 
> throw-away code that was a TLS server and client that we could use for testing 
> certificates.

I have a plan to avoid most of that mess.

We code and do our unit testing en clair.  Adding TLS negotiation
isn't the first step, it's the last.  (In Go, just one listener
initialization call changes.)  Once we know that the protocol machinery
works, and we've smoke-tested TLS operation, the "use TLS" switch
changes from default off to default on.

Documentation is an issue, yes.  Probably more work than the code.

> Are there any big chunks I didn't mention?

You've covered most of what I can see.

I'm gradually learning enough to write the guts of the TLS code myself
if I have to, but I'd rather not.  My plan from the beginning has been
to set up things so you and Ian and Gary and James can obsess about
the protocol-bashing while I (a) keep you supplied with tools and
weapons, (b) keep an eye on the architectural big picture, and (c)
review everything.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.