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

Re: Ahh! Leap year (February) miscalculation?



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?

--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