Driver strategy - we need to decide among incompatible goals

[Achim Gratz]

Eric S. Raymond via devel writes:
> 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.

There never were any drivers that required "proprietary binary blobs" in
(x)ntpd that I can remember.  That is unless you count firmware on the
clocks, in which case you'd need to throw out all current GPS support as
well.

> 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.

Before you start to go down that road remind us again what threat model
you are trying to protect against.  Any talk about security is hollow
theater without that bit of information.

> 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),

Whether the device ships ZDA messages or not, there simply isn't any
notion of a "year" in GPS, so any year you get with whatever number of
digits in whatever NMEA or proprietary message really is an imaginary
one.

> (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,

That includes any practical device that has ever been built.  Deal with
it.

> and (3) NTP era rollovers (one coming in 2036).

Ditto.

> 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. 

You won't make even a tiny step in that direction based on your current
understanding of the issues.

> 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.

Which are just as unreliable as two-digit years.  NTP is all about a
bunch of computers agreeing on time within some error bracket, not about
that notion of time being an absolute reference.

> 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.

You can't rely on any number of digits being correct either way, so if
you only have a single reference nothing of what you propose changes the
fact that you can't determine the correct time in all imaginalble
circumstances.

> 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.

So, all GPS receivers, to start with?  Most longwave radio transmitters
don't send the century digits out at all and GPS doesn't even know about
the year.  If you're suggesting to believe the pivoting whatever crappy
firmware does on the clocks as long as it gives you a four-digit year
number , then that's not improving anything.

> 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.

Would it surprise you to hear that while the Oncore receivers aren't
available anymore, there are (at least used to be) more modern receivers
that behave like one?  Ditto for the Motorola M12 and other "classic"
GPS.

[…]

How about an option 4. where you admit that full autonomy not only is
provably impossible to result in an absolute time with bounded error
margin, but also not even interesting to NTP.  That might get you to
recognize that the only way to synchronize to some notationally correct
time is to use as many _independent_ sources of time as you can get hold
of.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada