- Shipped
- August 19, 2026 at 2:19 AM UTC
- Author
- Kamo
- Commit
- cbc3ae8
KToken could not verify a real token. The four ids it carries are int64s, and the Java signer (kamo-shared-library KToken#canonicalForMac) appends each as a raw `long`, so all 19 digits go into the MAC material. This class read them with Number(), which rounds past 2^53, and every setter then applied `v|0` -- a 32-bit truncation on top of the rounding. 1168485648209608710 came out as a small integer, the recomputed HMAC did not match the one the server signed, and parseAndVerifyCookie returned null: a valid token read as forged. It only ever agreed with itself, on ids small enough to represent. The ids are now the cookie's own digit strings, so the material matches the signer byte for byte, and are validated by shape rather than by Number(), which would defeat the point. The expiry stays a number -- epoch seconds are ~1.8e9 and in no danger. Nothing calls parseAndVerifyCookie today; the cookie is forwarded to the services verbatim. So this fixes a landmine rather than an outage -- but it is a landmine in an auth path, where the failure would look like a rejected login rather than a rounding bug. Same change as kamo-internal f55a95c9, where it carries mutation-proven tests: 4 of the 6 fail against the previous implementation. This repo has no test runner.