leapsecond file

Ian Lepore
Wed, 24 Aug 2016 20:21:14 -0000

On Tue, 2016-08-23 at 22:40 -0700, Andreas Ott wrote:
> On Sun, Aug 07, 2016 at 09:44:55PM -0700, Kevin Oberman wrote:
> > On 11.0-BETA4 I have:
> > > grep expires /var/db/ntpd.leap-seconds.list
> > #    File expires on:  1 Jun 2017
> >
> > But I see what you do on 10.3-RELEASE.  Looks like the update has
> > not made
> > it into 10 (an I would guess 9).
>
> The flaw is in the internal versioning of files, it does fetch the
> newer
> file from IETF and puts it into /var/run/ntpd.leap-seconds.list, but
> although the expiry is newer, the FreeBSD onboard source version
> claims
> to be newer in the 'last update date in NTP timestamp format' line
> ...
>
> FreeBSD 10.3-RELEASE-p7 onboard source is in /etc/ntp/leap-seconds,
> which gets copied to /var/db/ntpd.leap-seconds.list. The fetch
> IETF file downloads to /var/run/ntpd.leap-seconds.list .
>
>
> [root at mon ~]# egrep -e Update\|expires\|^'#\$'
/etc/ntp/leap-seconds
> #       Last Update of leap second values:  31 Dec 2015
> #$       3660508800
> #       Updated through IERS Bulletin C 50
> #       File expires on:  1 Jun 2016
> [root at mon ~]# egrep -e Update\|expires\|^'#\$' /var/db/ntpd.leap
> -seconds.list
> #       Last Update of leap second values:  31 Dec 2015
> #$       3660508800
> #       Updated through IERS Bulletin C 50
> #       File expires on:  1 Jun 2016
> [root at mon ~]# egrep -e Update\|expires\|^'#\$'
/var/run/ntpd.leap
> -seconds.list
> #       Last Update of leap second values:   5 January 2015
> #$       3629404800
> #       Updated through IERS Bulletin C51
> #       File expires on:  28 December 2016
> [root at mon ~]#
>
> with the end result that the file from /var/run/ never gets moved to
> /var/db/ .
> The 480.leapfile-ntpd used by periodic calls the same rc file fetch
> and
> comparison.
>
> -andreas

The Last Update value reflects only additions of leap seconds to the
file, and it is specifically documented that Last Update does NOT
change when the file's expiration date is extended without changing the
other contents.

It looks like part of the problem here is that the Last Update value IS
changing when the leap data itself is not.  Our commit logs say the
files have been obtained from USNO.  Either USNO is violating the
standard in their files, or the value is getting modified before it's
commited to the freebsd repos.  (I'm adding Cy to the CC list, since he
committed them.)

It looks like the fetch/install decisions in rc.d/ntpd are not quite
right either.  Both Last Update and Expiration date have to be taken
into account.  To allow for these broken files that incorrectly change
the Last Update, workable logic would be to keep the file with the
highest Expiration date, and if the expirations are equal, then keep
the one with the highest Last Update.  (I think it would be better to
test Last Update first, then use Expiration as the tie-breaker, but
that fails with these broken files.)  Testing both Expiration and Last
Update will allow for a corrected file to be published after
accidentally publishing bad data, and we'd take the corrected file.

-- Ian