RFC: Remove `serialize._loads_v1` and `_loads_v2`

[woodruffw]

Opening this as an RFC because it's technically a behavioral change.

At the moment, CacheControl has 5 serialization "implementations":

• _loads_v0: legacy, currently a no-op
• _loads_v1: legacy, loads from a pickle file
• _loads_v2: legacy, loads from a zlib-compressed base64 stream
• _loads_v3: legacy, currently a no-op
• _loads_v4: the current msgpack-based serialization

These are all defined under cachecontrol.serialize, and are dispatched to based on the version in the cache entry's "header".

I propose removing _loads_v1 and _loads_v2 in a similar manner to v0/v3: we can just make them no-ops, meaning that any entries that happen to be found in those formats will be treated as cache-misses instead.

Rationale:

• For just _load_v1: loading from pickle files is well known to be dangerous.
• For both: both formats are very old, and were deprecated years ago (around 2017, with 0.12.0). As a result, any lingering cache entries that happen to be on still-running systems are very likely expired anyways.

Benefits:

• For _load_v1, removing an old and potentially dangerous deserialization surface
• For both: generally reducing the complexity of the de/serialization code, and allowing us to simplify the serialize.loads lookup logic

Thoughts? If this sounds reasonable, I'm happy to do it.

[woodruffw]

CC @frostming for opinions 🙂

[frostming]

It looks there is no big problem with v2 except for being too old? Seems someone wants to fallback to v2 when msgpack is not installed: #161. But that PR isn't ideal either because it would be a breaking change and we can't "opt-out" a feature in Python packaging system.

No objection for removing v1

[woodruffw]

It looks there is no big problem with v2 except for being too old?

Yeah, behaviorally it looks like it doesn't have any major security risks. That being said, it's also probably pretty slow and not space-efficient compared to msgpack and hasn't been the serialization default in a long time, so it should be entirely "dead" code at this point.

I'll start with v1 though, and we can revisit v2.

[frostming]

Thanks, let's do both as the best effort. We can add a v5 without msgpack someday when python packaging supports the opt-out feature.