Re: [gentoo-dev] Signed push & clock drift rejection

[Patrick McLean <chutzpah@gentoo.org>]

On Tue, 19 Jul 2016 13:22:29 -0700
Patrick McLean <chutzpah@gentoo.org> wrote:

> On Tue, 19 Jul 2016 21:23:16 +0300
> Andrew Savchenko <bircoph@gentoo.org> 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  
> 
>