[Bug 225029] [patch] ntpd expired leap seconds file not updated

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225029

            Bug ID: 225029
           Summary: [patch] ntpd expired leap seconds file not updated
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: ian at FreeBSD.org
          Keywords: patch

Created attachment 189563
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189563&action=edit
fixed logic for deciding when to install a new leapfile

In base r304780 a change was made to the logic that decides whether to install
a fetched leaplist file in place of the one currently in use.  The new logic
first compares the "version" number (last-update date), and only if the old and
new version are identical does it compare the expiration date.

Unfortunately, USNO (and maybe others) have misinterpreted the meaning of the
last-update field and they incorrectly increment it when changing the file
expiration date even if the leapsecond data has not changed.  This means that
if you ever obtain a file from USNO, when it expires it will not be replaced by
newer files from other sources, because it has a later (incorrect)
version/last-update.

The r304780 commit message says I suggested the change, but it appears what got
committed wasn't quite what I suggested.  Here's the text of my original
suggestion:

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.