Steven D'Aprano writes:
But if I'm distributing my code to others, the responsible thing to do is to think of the potential security risks about using pickle in my app, or library. What if they use it in ways that I didn't foresee, ways which *ought to be* safe except for my choice to use pickle?
If you have a choice, don't use pickle. If you don't have a choice, label your product "Uses pickle. If you care about security, find out what security issues that entails."
How do I use JSON to serialise an arbitrary instance of some class?
Ask Wes Turner about semantic JSON or whatever it is he frequently advocates for providing more type information to JSON codecs.
How do I know which other serialisation format is right?
That's your problem. We can advise you once you present your application and threat model(s). It does depend on both.
What about those -- and they are a significant minority -- who are restricted to only what's in the stdlib?
What about them?
Some awfully clever chappy found a way to add a magical "pickle.safeload()" function that did everything needed, safely. Would you oppose it?
I never oppose magic, for wizards are subtle and quick to anger. I have no desire to be turned into a newt. I just don't believe claims like "function that does everything needed, safely."
If you do *actively oppose* adding a safe version of pickle, perhaps you should explain why.
Define "safe": what is pickle allowed to do, what applications will be provided such "safety", and what threat model(s) is(are) being considered? Until somebody answers that, we all may as well sit this one out.