[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ahh! Leap year (February) miscalculation?



Cal Heldenbrand <cal@xxxxxxxxxxx> said:
> Great, thanks!  Out of curiosity, would this bug only happen during the 24
> hours of the missing February 29th?  Or would the clock skew be off 24 hours
> for the rest of the year?

Rest of the year. THat's why its so bad. Its good that BEFORE_SLOP work around
exists, but otherwise its really the worst kind of bug: disables the entire
installed base.

--Sampo

P.S. Release 0.79 is on the web site. Don't know why my announcement email has not
yet come through the list server.

> --Cal
> 
> On Tue, Mar 1, 2011 at 6:29 AM, <sampo@xxxxxxxxx> wrote:
> 
> > I am working to put out a fix still this morning.
> >
> > The fix is already in anongit.
> >
> > Release 0.79 will come to site as soon as it passes test suite.
> >
> > --Sampo
> >
> > P.S. timegm() is gnu extension so as I can not use gnu for licensing
> > reasons, I had to
> > reimplement it - and made bug. Now the test suite is more extensive in
> > testing it
> > so it should not happen again.
> >
> > Cal Heldenbrand <cal@xxxxxxxxxxx> said:
> > > Hi everyone,
> > >
> > > Right at 6:00pm Central (midnight GMT) all of my web servers started
> > > throwing login errors, showing a clock skew of 86400 seconds:
> > >
> > > t  zxidsso.c:476 zxid_validate_cond     zx E ssof: NotBefore rejected
> > with
> > > slop of 39600. Time to validity 86400 secs. Our gettimeofday: 1298938582
> > > secs, remote: 1299024982 secs
> > >
> > > The remote epoch calculation there is incorrect, it should be the same as
> > > "Our gettimeofday"   (The web servers and IdPs are in sync, within a
> > > second)  Is this a leap year problem?
> > >
> > > I managed to bandaid this for now by adding a BEFORE_SLOP of 2 days.
> >  Also,
> > > my zxid version is a little dated, at 0.69.  Apologies if this has
> > already
> > > been fixed!
> > >
> > > Thank you,
> > >
> > > --Cal