hazelcast / hazelcast/hazelcast-python-client

Consider replacing pickle serializer with a user-provided fallback serializer

Open
#363 1 comment 0 reactions 0 assignees View on GitHub
Source: Internal Type: Enhancement
Dominant language
Python
Stars
116
Forks
78
Avg merge
10d 22h
Merged PRs (30d)
1

Description

Pickle is currently used as the fallback serializer in the client. It is very convenient, but at the same time dangerous and causes surprising behavior.

First of all, Pickle is dangerous, since it is easy to be abuse it to execute arbitrary code. There are a many articles on the internet about that issue, such as this one: https://intoli.com/blog/dangerous-pickles/

Pickling data provides a false sense of "everything works OK" feeling. Although pickled data can only be deserialized on Python and if and only if all the classes present in pickled data are imported beforehand.

Consider the following example:
```python3
# module1/module2.py
class MyClass:
def __init__(self, value):
self.value = value
hz = HazelcastClient()
m = hz.get_map("mymap").blocking()
m.put("myobj", MyClass("foo"))
```
Since no serializer was assigned to `MyClass` fallback pickle serializer will be used. There are no warnings after `m.put` operation that the object can only be deserialized with Python code which also imports `module.module2.MyClass` beforehand.

I think a better way to handle this situation is, defaulting to no fallback serializer and providing the option to the user to specify it manually. So, if a class cannot be encoded we just raise an exception unless the user provided a fallback serializer (which could be pickle!).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.