Hacker News Reader

Comment by t0astbread | Hacker News Reader

My first thought was "How does it handle untrusted input?" and they have a page dedicated to it: https://rkyv.org/validation.html

But the phrasing on that page does not exactly inspire confidence ("...good defaults that will work for most archived types...", "...it's not possible or feasible to ensure data integrity with these use cases..."). Is this actually usable for untrusted data or is it mostly used in scenarios where you already know the data is fine?

View on HN

As for the second quote, the surrounding context explains that the validator will by default return an error if you point to a single object using two different pointers with different opinions on what the pointee's type is. This doesn't sound like a safety issue, since the validator is being too conservative rather than not conservative enough.

The first quote is probably in part referring to the second quote. If that is all it is referring to, than there is no safety issue. If there are other similar issues but rkyv chooses to reject valid archives rather than accept invalid ones, then there also is no safety issue. However, that isn't unambiguous, so I can't say for certain that it isn't possible to misuse the library from safe rust.

Author here, you’re correct. You can customize your validation context for your specific needs. For example, if you don’t have allocation available (i.e. `#![no_std]` without the alloc crate) then you’ll probably need to write your own mapping system to handle shared pointers. Or you can just not use them if that works better for you. That’s also a large part of why rkyv uses generics so heavily.

If your data is read-only then pointing to the same object from two locations is (usually) fine. But rkyv also supports in-place mutability, which requires validating that no two pointers will overlap each other. Otherwise you could have simultaneous mutable borrows to the same value which is UB.

Reply on news.ycombinator.com