From owner-freebsd-security@freebsd.org Wed Jul 1 13:55:45 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 33DBA990E00 for ; Wed, 1 Jul 2015 13:55:45 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 0A9531A9E for ; Wed, 1 Jul 2015 13:55:44 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4EE3A20C74 for ; Wed, 1 Jul 2015 09:55:42 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Wed, 01 Jul 2015 09:55:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=HR7G5uKYrAK5pys RnD2q5MtQ6fc=; b=atqRlIPoIg/UM6QssOOaz8KP251OKMy83ZcNyZCNkabkB8U wvch5falq+dYcJjIKO+J+ANWVMZUfPcNYbdtzdUFrvGPPVDxLhUC8IF6BoxjxTbx 8bYKtOl/NWNiB56BNrlIWfleJ1pNrEye4ROkV8HaJnVW1VQ6SIoBjvvCzf9o= Received: by web3.nyi.internal (Postfix, from userid 99) id 1533A106DE0; Wed, 1 Jul 2015 09:55:42 -0400 (EDT) Message-Id: <1435758941.105242.312562265.3103CECB@webmail.messagingengine.com> X-Sasl-Enc: W25WrwKN5mmo6Rv3uP+EBGPuNPv4l+aJJLtIGpcS/S7b 1435758941 From: Mark Felder To: =?ISO-8859-1?Q?Dag-Erling=20Sm=F8rgrav?= Cc: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: MessagingEngine.com Webmail Interface - ajax-eecef38c In-Reply-To: <86bnfwxa4m.fsf@nine.des.no> References: <1435154274.964221.306546033.052903CD@webmail.messagingengine.com> <86bnfwxa4m.fsf@nine.des.no> Subject: Re: Leap Second Date: Wed, 01 Jul 2015 08:55:41 -0500 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:55:45 -0000 On Wed, Jul 1, 2015, at 08:47, Dag-Erling Sm=F8rgrav wrote: > 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. >=20 > Answering a bit late, but no: in practical terms, only NTP works. Better late than never :-) > 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. >=20 Yeah, I think it's pretty obvious now that doing leapseconds in tzdata is a bad idea -- worse than leapseconds themselves maybe? :-) > > 1) FreeBSD server unaware of leapsecond due to no tzdata entry and not > > synced to NTP ends up 1 second off >=20 > 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. >=20 I was ignoring that bit, but it's worth pointing out to the readers. I should have worded it "...will be one *more* second off" :-)