Python ntpq lands - what to do next?

[Eric S. Raymond]

Reassured by Gary's finding that we can make standalone binaries from Python
using cxfreeze (which satifies a want expressed by 2sigma) I landed the Python
translation of ntpq this evening.

(Hal, I tested and it works both in-tree without installation and out of tree
after waf install. If you still have an environment-specific problem we'll
fix that.)

The good news: the peers spreadsheet now automatically resizes horizontally
in wide terminal emulator windows.

The bad news: Gary says it's 6x slower than the C version, and this
does not change when you cxfreeze it.  That's OK, it only needs to
operate at human speed. It seems unlikely anyone will ever care.

The better news: that's 7KLOC more gone.  We're now down to 67KLOC, which
is 29% of the original codebase size.

Now let me step back and remind everyone of the last strategic look
forward ("Forward-planning towards release 1.0", Wed Oct 5 04:27:10
UTC 2016) Here's the to-do list from that post exactly a month ago:

* Fix symmetric-peer mode and MS-SNTP, definitely.

* Drop broadcast client mode, wich Daniel rightly notes is
  fundamentally impossible to secure

* Fix broadcast server mode, because Mark says a lot of Windows client
  users rely on it, but add a strong warning that it's a bad idea and
  users should transition out ASAP.

My understanding is that symmetric-peer mode has been merged with
server mode.  Daniel, can you confirm?  Is it documented where it
needs to be?  I suspect not - I grepped for "symmetric" and found
references in assoc.txt, authentic.txt, disipline.txt, orphan.txt,
and select.txt that pretty clearly need to be changed.  (We probably
can't have symmetric loop errors any more, which is a good thing.)

Has MS-SNTP authentication been restored?  What is the state of
broadcast modes?

I then proposed three possible scenarios for working towards release.
We weren't feeling time pressure, so we ended up in Case Blue.  I note
that my schedule projection for landing Python ntpq was accurate to
the day. :-)

Daniel has been heard to say that with symmetric-peer mode out of the
picture there may no longer be a need to write a new restriction
language.  That's just as well in my opinion as it would reduce the
friction of adoption.

However, Daniel has also said the default restrictions are a security
problem.  Daniel, would you say more about that, please?  What, if
anything, do we need to change?

Mark has noted that we need to carry packaging help and possibly
metadata for major distributions.  I don't know that anyone has
taken it on.

We have 5 bugs on the tracker.  Three of them relate to the GPSD
refclock, which I think may not be useful enough to be worth saving.
Gary disagrees.  I think that means Gary gets to fix it.  If it doesn't
get fixed and becomes the last remaining 1.0 blocker, I'm reserving
the option to yank it on grounds of too crappy to ship.

One bug is an issue Hal Murray seems to understand but I don't.

As for me, I think my next two tasks are (1) write the nice sizzly
ntpmon tool we've been discussing, and (2) move ntpdig to Python.
That'll drop 3 more KLOC and remove our libevent2 dependency.

Neither job will be difficult, because I've already built back-end machinery
to speak Mode 6 packets in Python (including authenticated mode 6) that
can be used for ntpmon and adapted to speak SNTP.

In summary, here is my list of pre-1.0 issues and the people who seem
to own them.

* Documentation update for abolition of symmetric-peer mode. (Daniel.)

* MS-SNTP support (Daniel).

* Decision, implementation, and documentation on brodcast modes (Daniel).

* Do we really not need a new restrict language?  What defaults need to
  change? (Daniel)

* Package metadata for major distributions (?).

* Tracker issues related to refclocks #20 and #46 (Gary).

* Tracker issue #44 (Hal).

* ntpmon and Python ntpdig (myself).
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>