From owner-freebsd-security@freebsd.org Wed Jul 1 13:47:40 2015 Return-Path: Delivered-To: freebsd-security@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 82107990BC4 for ; Wed, 1 Jul 2015 13:47:40 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4884C2FB7; Wed, 1 Jul 2015 13:47:39 +0000 (UTC) (envelope-from des@des.no) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 276DA448E; Wed, 1 Jul 2015 13:47:39 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 4BFD41C1B; Wed, 1 Jul 2015 15:47:37 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark Felder Cc: freebsd-security@freebsd.org Subject: Re: Leap Second References: <1435154274.964221.306546033.052903CD@webmail.messagingengine.com> Date: Wed, 01 Jul 2015 15:47:37 +0200 In-Reply-To: <1435154274.964221.306546033.052903CD@webmail.messagingengine.com> (Mark Felder's message of "Wed, 24 Jun 2015 08:57:54 -0500") Message-ID: <86bnfwxa4m.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 13:47:40 -0000 Mark Felder writes: > I'm not an expert on the leapsecond operation, but if I understand it > correctly there are two ways a system can be notified of a leapsecond: > via a tzdata update or through NTP. Answering a bit late, but no: in practical terms, only NTP works. Recording leap seconds in tzdata breaks POSIX and a lot of assumptions in existing code, not only on the day a leap second occurs but at any time in history after at least one leap second has occurred. > 1) FreeBSD server unaware of leapsecond due to no tzdata entry and not > synced to NTP ends up 1 second off A server which is not synchronized with a reliable external source will end up a lot more than one second off regardless of leap seconds, because it relies solely on onboard RTCs and oscillators which are both inaccurate and imprecise. Clock drift will be measured in seconds per week and vary depending on CPU load, disk I/O, the phase of the moon and your dog's horoscope. > 2) FreeBSD server unaware of leapsecond due to no tzdata entry synced to > leapsecond-aware NTP server successfully handles leapsecond Correct. > 3) FreeBSD server unaware of leapsecond due to no tzdata entry acting as > NTP server doesn't notify clients of leapsecond and they end up 1 second > off This assumes that the hypothetical server is not synchronized with a reliable external source, which is a broken setup to begin with (see 1). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no