The state of NTPsec as I see it

[Eric S. Raymond]

Until this week, I had two remaining surgeries I wanted to do on the C
code before we ship 1.0. One of them was getting rid of sockaddr_u in
favor of ANSI sockaddr_storage. The other, rather larger one, id
getting rid of interface scanning and having all packets enter through
the IPv4/IPv6 wildcard address.

I've now temporarily abandoned getting rid of sockaddr_u.  The reason
from this move was to get rid of the last real union construct in the
codebase, as prep for moving it to Rust or Go.  However, I have
learned from an old ChangeLog comment that thus would increase the
memory footprint of the MRU list, so I've decided it to defer it
until we actually commit to moving out of C.  I've done most of the
prep-work, hiding the interface to that structure, so it should
be pretty easy when it needs to be finished.

Getting rid of interface scanning is still in the plan, as this would
abolish a rather large amount of code complexity and one of the very
few non-POSIX dependencies we have left.  To go forward I need to get
a brain dump from Daniel about some aspects of ntpd/ntp_io.c that he
seems to have grasped better than I do as yet.

The codebase is down to 61KLOC of the original 231 - 26%.  Dropping
interface scanning might pare off most of another KLOC.  I don't
see any other significant cuts coming unless we drop more obsolete
refclocks.  I'd like to get us to 25% for PR reasons - 1:4 is a nice
inpressive ratio to fling around.

To my knowledge there are only three nontrivial things standing between
us and a quality 1.0 release:

1. The waf recipe needs some unsnarling.  There are a bunch of minor
glitches in the build that are related to overcomplexity in the
present build recipe.  If I could have one wish right now (other than
real funding) it would be for someone else to step up to take
responsibility for this.

2. We need packaging metadata for major distributions.

3. The JSON refclock is a mess that has never worked quite right,
without a clear purpose in life. I'd prefer to drop it, unless
somebody steps up to fix it.

I continue to have every reason (including long-term stability on the
test-farm machines) to believe that the codebase is generally rock-solid and
unlikely to give trouble under field conditions.

Have I missed anything major on anyone's issue list?

What I'd *like* to be doing right now is (1) writing ntpshark, and (2)
experimenting with a port to Go.  I think a Go port would easily drop
another 20 KLOC, besides of course banishing buffer overruns and
memory-allocation bugs forever.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The day will come when the mystical generation of Jesus by the Supreme
Being as his father, in the womb of a virgin, will be classed with the
fable of the generation of Minerva in the brain of Jupiter.
	-- Thomas Jefferson, 1823