[nurettin]

My current rpc model for python is to pickle function name and args/kwargs and publish to redis for any subscribers that might be listening.

If the channel is marked as persisting, I put the message to a hashset with current nanosecond as the timestamp and just send a ping instead.

It is pretty fast with asyncio redis client clocking at an avg 15k rpc/s on a single core with uvloop on a lowly i7

[JoshTriplett]

Be careful using the pickle format; it's not considered safe to unpickle untrusted data. https://docs.python.org/3/library/pickle.html

[nurettin]

I did see the big warning labels everywhere. However, there is simply no replacement that is equally fast (protocol 5), easy to use (copyreg) and imports necessary modules when deserializing. So tradeoffs were made.

[JoshTriplett]

> imports necessary modules when deserializing

This is one of the fundamental security issues.

[nurettin]

Most of the security issues are mitigated if you are only running the software internally. But it would be interesting to see a hacker who managed to get into the production systems somehow figure out your RPC scheme and try to craft packets to exploit it instead of going directly for the user/password database.

[ngneer]

You beat me to it. Sounds like you would be opening yourself up to a variant of CSRF. One user could upload untrusted data that would be fed into an unsuspecting user. You should never feed or consume an untrusted pickle.

[philsnow]

Pickles can also be time bombs, especially around python upgrades. Sometimes (ok, rarely) the serialization / deserialization of some types changes between versions of python.

Another issue is painting yourself into a corner: when you use pickles, you make it harder to either switch away from python in the future or consume the same serialized objects from any non-python (micro)service. This can delay or prevent transitions away from python that would otherwise make sense.