From owner-freebsd-stable@freebsd.org Wed Aug 24 20:22:32 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15022BC5063 for ; Wed, 24 Aug 2016 20:22:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6FA551E57 for ; Wed, 24 Aug 2016 20:22:30 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 53572a5a-6a38-11e6-8a83-176deb810eee X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 24 Aug 2016 20:21:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u7OKLEBt005007; Wed, 24 Aug 2016 14:21:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1472070074.1430.39.camel@freebsd.org> Subject: Re: leapsecond file From: Ian Lepore To: Andreas Ott , Kevin Oberman Cc: Randy Bush , FreeBSD Stable , Cy Schubert Date: Wed, 24 Aug 2016 14:21:14 -0600 In-Reply-To: <20160823224030.A9828@naund.org> References: <8092297e-7a0a-12c4-e115-4ed81d28f123@protected-networks.net> <20160823224030.A9828@naund.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 20:22:32 -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@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@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@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@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