From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9C25713832E for ; Tue, 19 Jul 2016 20:28:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2884E21C0C6; Tue, 19 Jul 2016 20:28:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3344221C028 for ; Tue, 19 Jul 2016 20:28:24 +0000 (UTC) Received: from patrickm (unknown [100.42.98.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: chutzpah) by smtp.gentoo.org (Postfix) with ESMTPSA id C95DB340CB8; Tue, 19 Jul 2016 20:28:22 +0000 (UTC) Date: Tue, 19 Jul 2016 13:28:20 -0700 From: Patrick McLean To: Andrew Savchenko Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Signed push & clock drift rejection Message-ID: <20160719132820.4856dfd3@patrickm> In-Reply-To: <20160719132229.598ccee8@patrickm> References: <20160716123309.940bdcbcb2c28d0aa26aa730@gentoo.org> <20160718200335.ukkvr5l42uzqv2hr@schiffbauer.net> <20160718232709.7756942377a33c34ce488d87@gentoo.org> <20160719022122.GA26527@waltdnes.org> <20160719212316.238d624977400260bc31b86d@gentoo.org> <20160719132229.598ccee8@patrickm> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: d4c91ef1-ea7f-4415-890a-a3e902a38913 X-Archives-Hash: 5e2dd634a8dd9817bbd13158a64ab00b On Tue, 19 Jul 2016 13:22:29 -0700 Patrick McLean wrote: > On Tue, 19 Jul 2016 21:23:16 +0300 > Andrew Savchenko wrote: > > On Mon, 18 Jul 2016 22:21:22 -0400 waltdnes@waltdnes.org wrote: > > > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko > > > wrote > > > > > > > > As I wrote earlier in this thread, ntp server is not a guarantee > > > > that such problems will not happen. If hardware clocked was > > > > significantly offset during boot, it may take several _hours_ > > > > for ntp to fix this via clock skew. Apparantly commit may be > > > > made during these several hours. > > > > > > I'm amazed that "robust linux servers" are deathly afraid of > > > simply setting the time, and being done with it. And while we're > > > at it, if a developer is doing development on a server machine, > > > he may have other problems to worry about. At home I occasionally > > > manually run a script that includes the 2 lines... > > > > I never said anything about "robust linux servers". If you think > > than only servers need a gradual clock slew instead of stepping, > > you are mistaken. > > > > > /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org > > > /usr/bin/sudo /sbin/hwclock --systohc > > > > And if time delta is significant, the system may become broken > > this way. Congratulations. > > Really? I have many times skewed time by weeks using ntpdate with no > issues. > > > The gradual NTP time slew was not invented because people were lazy > > to run two simple commands. Actually it is just the opposite: > > setting system time via a single huge step is much easier to > > implement than a proper adjustment via a series of small time slews. > > For servers it is indeed important in many ways, including > > time stamp based cryptography as kerberos or database integrity. > > Sure randomly skewing time can cause weird issues, which is why it is > a manual operation (and/or boot time operation). > > > > > But desktops also do need a proper time adjustment: > > - Filesystems will not operate correctly with time stamps in > > future, in the best keys they will be marked/reported as needed a > > repair procedure. > > I have only ever seen ext4 complain about the superblock timestamp, > and fsck generally just corrects without issue, and it generally is > only an issue after a reboot. > > > - Cron jobs may go broken too as chithanh mentioned already. > > Get a better crond? Decent cron daemons can detect time skews and act > accordingly. > > > - Video encoding is not happy with time shifts at all. While small > > predictable slews can be tolerated, large jumps will just broke the > > process. > > Anything that cares about having a monotonic clock, and doesn't > actually care about the real time (like video encoding) should just > use the monotonic clock, not the system time. > > > - System may become *vulnerable* because of time stamp based attack. > > Though it is not easy to use such behaviour, it is still possible. > > Once again, monotonic clock exists for a reason. If you want to > talk about vulnerabilities, you do realize that doesn't work properly > unless the client and server have reasonably similar system times. > Err, SSL doesn't work properly. > > - and many more... > > > > Best regards, > > Andrew Savchenko > >