4 ms·
> * Insecure: If you are unpickling insecure code, you have other problems. Deserializers should not be used as a protection against hacking. There are lots of
by price 6y ago
> * Insecure: If you are unpickling insecure code, you have other problems. Deserializers should not be used as a protection against hacking.
There are lots of good use cases for deserializing untrusted data -- it's what you do in almost any client-server situation. So the fact you can't do this with pickle really is an important limitation.
- manicdee 6y agoIn what client server situation does it make sense to use pickles over JSON/YAML?
- hyperpape 6y agoNone, except when you're taking a huge shortcut. Which is why you want to be super cautious about using Pickle, or Java serialization, or any serialization solution that deserializes arbitrary objects. Once your deserialization isn't explicit about what objects you accept, you have to be super careful about the provenance of that data.
- price 6y agoLike hyperpape said, virtually none. And this point is the biggest reason why. The article is, after all, about reasons not to use pickle. :-)
- nurettin 6y ago> There are lots of good use cases for deserializing untrusted data Yes, and untrusted user data should not have arrived at the system in pickle format. And in case of RoR, it should not have arrived in YAML format or loaded with YAML.load[1] So my point stands. [1] https://gist.github.com/niklasb/df9dba3097df536820888aeb4de3284f https://gist.github.com/niklasb/df9dba3097df536820888aeb4de3...