Repository navigation
Trailing bytes are accepted by msgpack@1, the envelope and the handshake #33
Description
MsgPack::decode (and, since #31, decode_seed) is rmp_serde::from_slice, which reads one value and never checks the rest of the input. So msgpack@1 accepts bytes with junk after the value. packed@1 and json@1 refuse them.
That leaves a gap in strictness between the official formats, in the reference itself. Every other runtime has to copy it to stay conformant, and a corrupted or concatenated frame body decodes silently.
Options:
- Make
msgpack@1refuse trailing bytes, by checking that the reader is exhausted after the value, asPacked::decode_seeddoes. This is a behaviour change to a versioned format's decoder, so it needs a call under schema compatibility: stricter decoding of what no conformant writer produces. - Keep it, and state it in
profiles/msgpack@1.jsonwith a proving vector, so every runtime matches it deliberately rather than by accident.
Found while building runtime#29 stage 1 (#31).
Activity
[-]msgpack@1 accepts trailing bytes after a value[/-][+]Trailing bytes are accepted by msgpack@1, the envelope and the handshake[/+]Kinflou commentedon Oct 25, 2026
The fuzz targets (#37) found the same gap in two more decoders, in both the Rust and TypeScript runtimes:
Envelope::decodereads[2, junk…]as aFault, ignoring everything after the tag.HandshakeFrame::decodereads only the first 31 bytes and ignores the rest.#37's
framing_decodetarget treats these two as non-canonical by design for now: their re-encoding must be a prefix of the input. Every other binary frame has to re-encode exactly. The decision here covers all three: refuse trailing bytes (a vector change for every runtime), or state the leniency in the profiles with vectors that prove it.