4 ms·
I appreciate the response, but the link you gave only states that the value returned by from_reader is strongly typed; it says nothing about what from_reader mi
by tetromino_ 4y ago
I appreciate the response, but the link you gave only states that the value returned by from_reader is strongly typed; it says nothing about what from_reader might be doing internally before it returns that value.
The actual answer seems to be https://github.com/serde-rs/serde/issues/1087#issuecomment-343030233 https://github.com/serde-rs/serde/issues/1087#issuecomment-3... - no security implications if no manually implemented Deserialize impls linked to by your application have security implications.
- chrismorgan 4y agoWell that’s just common sense. You write the deserialiser, it’s your responsibility. It’s no security implication in Serde or Ron.
- tetromino_ 4y agoThe interesting part is that it's also your responsibility to audit deserializer code in your dependencies.
- chrismorgan 4y agoThat’s still just a normal aspect of code. If you care about security, you have to audit all your dependencies. Security concerns in deserialising come about due to the input being able to control things, things like Python’s Pickle protocol where you get arbitrary object instantiation and function calls, even of things like os.system (pickle.loads(b"cos\nsystem\n(S'echo ACE'\ntR.")). Security cannot reasonably be retrofitted to such a model. With the likes of Serde (and indeed structural serialisers/deserialisers in practically every ahead-of-time-compiled language), this isn’t an issue: only the code controls things, and only types that declare a way of deserialising can be deserialised to.