Driver strategy - we need to decide among incompatible goals

[Eric S. Raymond]

Issue #608, "Future need for oncore GPS driver", foregrounds a product
strategy question we need to make a decision about.

In the early days of this project, we had a conflict between two objectives:

1. In order not to upset the NTP Classic userbase, support whatever 
old hardware we can determine they still care about.

2. Remove support for device classes that pose an unacceptable
security risk, e.g. by requiring proprietary binary blobs to be 
linked to the kernel.

We resolved that one by removing a couple of risky drivers. We never
got any pushback at all about this.

I wrote about this bit of history because it's a precedent for
narrowing our hardware support in order to improve our security
and reduce our expected downstream defect rate.

You're all aware that there is a nasty swamp of error states around
three problems: (1) Two-digit year reporting from some devices
(including NMEA GPSes that don't ship GPZDA), (2) wraparound
in date reporting - devices with a time counter of limit size
(including GPses) can wrap around at any time and start reporting
dates in the far past, and (3) NTP era rollovers (one coming in
2036).

NTPsec aims to be highly secure and reliable.  If we're serious about
that, we need to reduce our vulnerability to defects from these
wraparound/rollover problems. 

There's a related issue about running autonomously, e.g with only 
local GPSes or clock radios and no upstream NTP servers.  Used to be
you couldn't do this.  In 2017 I figured out why and fixed it. But
the ability to run automomous depends on your clocks shipping full 
4-digit years.

After doing this, I marked every driver type that could only ship
2-digit years deprecated. That set is Arbiter, certain modes of the
Generic driver, certain modes of the JJY driver, certain modes of the
Modem driver, the Neoclock driver, the Oncore driver, and the 
Spectracom Type 2 driver.  NMEA GPSes sometimes report a 4-digit year
(if they ship GPZDA) and sometimes don't.

My thinking was that we would eventually drop all of the 2-digit-only
modes and drivers, and say "if your refclock doesn't ship 4-digit
years, it's disqualified".  Besides the autonomy issue, devices with
this quirk are often very old hardware with wraparound problems.

Now we have a request to remove the deprecation marker from the Oncore
driver. The Oncore product line is EOL, but we are told there are 
receivers still in production that can use this driver.

We have a couple of possible responses to this problem.  Which one we 
choose depends on what our priority is.

1. If our highest priority is not annoying anyone whose hardware
support expectations were formed by NTP Classic, then yes, we should
un-deprecate Oncore.

2. If we think our actual customers consider replacing hardware a
trivial cost and would prefer correctness and autonomy guarantees,
we shoot *all* the 2-digit-year drivers and modes through the head.

3. Compromise. Support drivers and modes that only ship two-digit
years but require the user to somehow configure their
century/wraparound state.

This is really a product-strategy decision about which group of
cutomers we want to put first.  The Ciscos and AWSes and Azures of
the world do not care about keeping 20-year-old clocks running with 
potentially dodgy patches for wraparound problems.  Hobbyists care 
about that a lot. Some potential project contributors are hobbyists,
which gives us some reason to care aout them.

If it were up to me alone, I'd go with (2) - correctness and autonomy
over supporting old hardware.  The compromise (3) looks attractive 
at first sight, but I am wary of "add a config option" patches;
they add complexity and get you grief from misconfigurations.

Also present in my thinking is that if we go with (2) we get to drop
more lines of code and further reduce attack surface.  This is 
always a good thing.

Discuss...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Gun control" is a job-safety program for criminals.