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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel