.forge/issues/86638bd1-4ac6-4330-9f96-e48b1a46492f/issue.md

.forge/issues/86638bd1-4ac6-4330-9f96-e48b1a46492f/issue.md 1.3 KiB 33 lines Raw

id: 86638bd1-4ac6-4330-9f96-e48b1a46492f title: 'build: bound and validate timestamps (hostile dates panic or normalize)' state: closed labels:

kind:security assignees: [] milestone: null created: 2026-10-27T17:24:52.374686455Z updated: 2026-10-27T17:45:41.656486299Z

What

parse_ts_secs (src/build.rs:525) accepts arbitrary years and only checks 1..=31 for the day.

created: 100000000000000000-01-01T00:00:00Z → panic at src/build.rs:588 (attempt to multiply with overflow) in debug; release silently wraps.
created: 2026-02-31T00:00:00Z → the page's time title says 2026-03-03 00:00 UTC (civil-days normalization) while datetime keeps 2026-02-31.
Negative extremes (-9223372036854775808-…) can overflow in y2 - 399.

An issue file with the hostile created values; hu13 build exits 101 in debug.

A repo-controlled .forge timestamp crashes the build (DoS) or renders a date that was never written. Users reviewing pages see contradictory dates.

Bound the year (e.g. 1..=9999) before doing date math.
Validate day against month/leap year (or use a checked calendar conversion and reject overflow).
Use checked arithmetic or early bounds so no input can panic.
Tests: huge positive/negative year, Feb 31, Apr 31, Feb 29 non-leap/leap, valid git YYYY-MM-DD HH:MM:SS ±HHMM.