Date: Tue, 09 Jan 2018 17:44:53 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 225029] [patch] ntpd expired leap seconds file not updated Message-ID: <bug-225029-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225029 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@FreeBSD.org Reporter: ian@FreeBSD.org Keywords: patch Created attachment 189563 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D189563&action= =3Dedit fixed logic for deciding when to install a new leapfile In base r304780 a change was made to the logic that decides whether to inst= all 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 t= he last-update field and they incorrectly increment it when changing the file expiration date even if the leapsecond data has not changed. This means th= at if you ever obtain a file from USNO, when it expires it will not be replace= d 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-225029-8>