Option 2. If the manufacturer won't support the product any more, we shouldn't either.
On Thu, Aug 8, 2019 at 8:36 AM Eric S. Raymond via devel <devel@ntpsec.org> wrote: > > 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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel