If I feed arbitrary and potentially malicious bytes to postcard::from_bytes(), my expectation is that the deserialization fails with an error result, as opposed to an undesirable behavior such as (1) panicking, (2) unsafe/undefined behavior, or (3) a non-terminating algorithm.
If this is already the case, it would be nice to document it. For bonus points, add fuzz testing, too.
This might be the case, but I am working on squashing out any panic'ing branches. I would consider any a bug, but without fuzz testing and/or more review, I can't guarantee this yet.
This should never be the case. There are some uses of unsafe code, however this is generally limited to buffer management, with bounded checks based on the buffers provided by the user. I could add miri tests (with fuzzing) to also help guarantee this
I do not believe this is possible at all. Postcard does not support data structures that would be deserialized in some non-terminating way, such as compressed references that create some kind of loop, which means the runtime is bounded by the number of bytes provided, which can be bounded by the user (e.g. never try and deserialize items >= 10KiB or something).
I'll add docs that discuss this, and if possible add some rudimentary fuzz/miri testing.
If I feed arbitrary and potentially malicious bytes to
postcard::from_bytes()
, my expectation is that the deserialization fails with an error result, as opposed to an undesirable behavior such as (1) panicking, (2) unsafe/undefined behavior, or (3) a non-terminating algorithm.If this is already the case, it would be nice to document it. For bonus points, add fuzz testing, too.
Related: https://github.com/serde-rs/serde/issues/1087