The clock skew is apparently stored in a signed data type. Setting the clock skew to a sufficient large number results in the clock skew being interpreted as a negative number which results in every message being rejected as expired.
Environment
None
Activity
Rod Widdowson
June 10, 2010 at 4:51 AM
(edited)
Minor nit - the change is for 28 weeks (60*60*24*7*28). It irrelevant really - it's just a bignum.
Simpler fix, cap the value at 28 days worth of skew.
Scott Cantor
September 25, 2008 at 2:58 PM
Actually skew is stored as unsigned int. I think the problem is that time_t is signed on Linux, and probably other places, and is also still 32-bit a lot of the time, so a large skew causes the calculation to wrap.
The problem is that the "most allowable skew" depends on the values I have to modify with it, so telling when it's going to wrap is tricky.
I guess I could just limit it to something reasonable.
The clock skew is apparently stored in a signed data type. Setting the clock skew to a sufficient large number results in the clock skew being interpreted as a negative number which results in every message being rejected as expired.