Commit 348714d
fix(reports): asset-token format → fixed-length sig, no period collision
CI flake during 0.9.0's first publish run surfaced a real
production bug, not a test issue.
`mint_asset_token` was encoding `<payload> b"." <32-byte-hmac>`
and `verify_asset_token` recovered the two halves via
`decoded.rsplit(b".", 1)`. That works ONLY when the random HMAC
output contains no ASCII period byte (0x2E). With a 32-byte
SHA-256 output the per-token collision rate is
P("`.` somewhere in sig") = 1 − (255/256)**32 ≈ 11.8 %
i.e. roughly one in nine asset-token verifications would silently
fail and the user would get 401 → reload → fresh token → eventually
work. Locally we got lucky for weeks; CI hit the bad bytes today.
Fix: drop the printable separator entirely. SHA-256 output is
always exactly `hashlib.sha256().digest_size` (32) bytes, so
`payload, sig = decoded[:-_SIG_LEN], decoded[-_SIG_LEN:]` is
unambiguous. The `_SIG_LEN` constant is derived from `hashlib`
rather than literal-32 so a hypothetical future SHA-512 swap
doesn't introduce a fresh off-by-31 bug.
Token format change is wire-incompatible. Tokens minted with the
old format (`.` separator) fail verify after the fix. Acceptable
because:
- TTL is 1 hour by default → at most one hour of in-flight tokens
hit a 401, the user reloads, the freshly-minted post-fix token
works.
- Asset tokens never persist server-side (no DB row, no cookie
outside the iframe URL the page just minted), so there's no
upgrade-path migration to write.
- Anyone bookmarking an iframe URL is already living dangerously
vis-à-vis the 1-hour TTL.
Regression test (`test_round_trip_when_signature_contains_period_byte`)
sweeps `ttl_seconds` until the HMAC output contains a `.` byte
(typically within ~10 attempts), then mints + verifies. Pre-fix
that test fails deterministically; post-fix it passes
deterministically. 107 / 107 reports tests green locally.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>1 parent 55f36a8 commit 348714d
2 files changed
Lines changed: 73 additions & 6 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
52 | 52 | | |
53 | 53 | | |
54 | 54 | | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
| 58 | + | |
| 59 | + | |
| 60 | + | |
| 61 | + | |
| 62 | + | |
| 63 | + | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
55 | 67 | | |
56 | 68 | | |
57 | 69 | | |
58 | 70 | | |
59 | 71 | | |
60 | 72 | | |
61 | 73 | | |
62 | | - | |
| 74 | + | |
63 | 75 | | |
64 | 76 | | |
65 | 77 | | |
| |||
74 | 86 | | |
75 | 87 | | |
76 | 88 | | |
77 | | - | |
78 | | - | |
79 | | - | |
| 89 | + | |
| 90 | + | |
| 91 | + | |
| 92 | + | |
80 | 93 | | |
81 | | - | |
| 94 | + | |
82 | 95 | | |
83 | 96 | | |
84 | 97 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
59 | 59 | | |
60 | 60 | | |
61 | 61 | | |
62 | | - | |
| 62 | + | |
| 63 | + | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
| 81 | + | |
| 82 | + | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
| 88 | + | |
| 89 | + | |
| 90 | + | |
| 91 | + | |
| 92 | + | |
| 93 | + | |
| 94 | + | |
| 95 | + | |
| 96 | + | |
| 97 | + | |
| 98 | + | |
| 99 | + | |
| 100 | + | |
| 101 | + | |
| 102 | + | |
| 103 | + | |
| 104 | + | |
| 105 | + | |
| 106 | + | |
| 107 | + | |
| 108 | + | |
| 109 | + | |
| 110 | + | |
| 111 | + | |
| 112 | + | |
| 113 | + | |
| 114 | + | |
| 115 | + | |
| 116 | + | |
63 | 117 | | |
64 | 118 | | |
65 | 119 | | |
| |||
0 commit comments