Time to slow down and be more careful

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> >> I changed things so that there is never a conversion from l_fp
> >> to full time. There is a subtract done on the l_fp side.  The clock
> >> offset in l_fp is converted to an offset in seconds.  I think it's a
> >> double.  That eventually turns into a clock adjustment.  There is
> >> no explicit pivot.  There is an implicit pivot of the current time.
> 
> > I'm actually not sure which code you're talking about here, and I think it's
> > important that I should. 
> 
> You added some pivot code to step_systime in libntp/systime.c
> I don't understand why.

I didn't "add" a damn thing.  I restored the pivot computation that was there
before it was mistakenly removed.  You can compare the Classic version to
check this; there are some superficial differences due to the l_fp and macro
cleanups but the logic is the same.

> The argument is a time step as a double.  That comes from packets exchanged with a server using l_fp.  That's at most 31 bits plus sign, relative to the current system time.  That's the biggest step you can take.  You can step across epoch boundaries.  You can't step over whole epochs.

Maximum step size isn't the problem.

The problem, which is invisible now but won't be in the future, is
that any given l_fp can represent a countable infinity of timestamps
separated from each other by the 136-year cycle lengths.  Which one it
*actually* represents depends on the base epoch of the sending ntpd,
which we don't know.

Mills's solution was to map the timestamp to whichever of these
aleph-0 possibilities is closest in time to a pivot.  Then, if the
time intended by the sender was within a half-cycle of the pivot, all
is good.  That's what this code is doing.

Now, you might think the smart thing to do is pivot around now, but
*what if your system clock isn't reliable?* Like, you're running on an
RTC-less system and it comes up zero.  Mills's workaround against this
possibility was to pivot on the ntpd's build date.

This is why, if the same distros that didn't insist on Classic having
reproducible builds get a wild hair and pressure us to do it, we have
to tell them no.  If we take out the build-time pivot we create subtle
risks to future systems that happen not to have reliable clocks; best
case, you'd get good sources being rejected as falsetickers because
a timestamp was pivoted to the wrong era.  Weirder things could occur.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.