Driver strategy - we need to decide among incompatible goals

[Daniel Franke]

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 at 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 at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel