fix: parse RRSIG timestamps in UTC and accept dates past 2038年01月19日 #116

tobez commented 2026年05月11日 15:54:51 +02:00

SvenVD-be reported that validns rejects any RRSIG with an inception or expiration timestamp after 2038年01月19日 03:14:07 UTC with "signature expiration is not valid". The cause was a hard year > 2037 cap in the YYYYMMDDHHMMSS parser. The same parser also used mktime(), which interprets the broken-down time as local time, but RFC 4034 §3.1.5 specifies the field as a 32-bit unsigned count of UTC seconds since 1970.

extract_timestamp() now computes the epoch arithmetically in UTC and accepts the full uint32 range (through 2106年02月07日 06:28:15 UTC). The result is independent of the host time zone. Two signed-zone fixtures under t/issues/89-year-2038-timestamp/ — one window crossing the boundary, one fully past it — guard against regression.

Fixes #89

SvenVD-be reported that validns rejects any RRSIG with an inception or expiration timestamp after 2038年01月19日 03:14:07 UTC with "signature expiration is not valid". The cause was a hard `year > 2037` cap in the YYYYMMDDHHMMSS parser. The same parser also used `mktime()`, which interprets the broken-down time as local time, but RFC 4034 §3.1.5 specifies the field as a 32-bit unsigned count of UTC seconds since 1970. `extract_timestamp()` now computes the epoch arithmetically in UTC and accepts the full uint32 range (through 2106年02月07日 06:28:15 UTC). The result is independent of the host time zone. Two signed-zone fixtures under `t/issues/89-year-2038-timestamp/` — one window crossing the boundary, one fully past it — guard against regression. Fixes #89

jelu commented 2026年05月12日 10:36:02 +02:00

#build

#build