e3375530f6
The new max_ms check bounded nothing, because a policy could set max_ms up to
2^53 − 1. A still's piece could then state 2^32 − 1 frames. Rust hashed once
per stated frame (about 29 minutes), and Python built a list of n references
(about 34 GB).
- **§3.4 item 5 and §4.4.** max_ms is at most 600000, and at most 2^24 units on
every component's timebase. Both are policy-piece-bounds, in both readers.
§4.4 gives the reason: a verifier takes a piece whole, so the longest piece
bounds its work. Ten minutes is far past any piece a delivery cuts, and 2^24
units bounds the work on any timebase, which may have up to 2^32 − 1 units a
second.
- **§11.3, before any frame is decoded.** Each piece's floor object, where its
framing reads, must hold one unit per frame of its piece
(floor-object-mismatch). Both verifiers make this check first.
- **Held stills.** Python holds a still's frame and its count (Held) and hashes
the digest a block at a time. Rust's held_digest also feeds a block at a time.
- **Corpus.**
- refusals: max_ms 600001; and the default max_ms on a timebase of 2^32 − 1
units a second.
- policy/max-piece.toml: accepted at both bounds.
- staged-mutations max-ms-past-cap (policy-piece-bounds).
- staged-mutations still-at-cap: the still given the longest piece the policy
allows, its manifest naming the frames, refused by the floor count in both
verifiers.
- **policy_diff.** Its random policies now reach both bounds.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
17 lines
335 B
TOML
17 lines
335 B
TOML
# Refused: the default max_ms (4000) is past 2^24 units on a timebase of 2^32 − 1 units a
|
||
# second (§4.4).
|
||
schema = "wai.pack.policy/1"
|
||
asset_id = "r"
|
||
lead = "v"
|
||
|
||
[[component]]
|
||
id = "v"
|
||
media = "video"
|
||
timebase = { num = 4294967295, den = 1 }
|
||
|
||
[[ladder]]
|
||
id = "b0"
|
||
component = "v"
|
||
capability = "wai.video.int_motion"
|
||
role = "base"
|
||
|