Restrict pickle deserialization to safe types (CVE-2025-69872)

[a2811057970]

Summary

Mitigates CVE-2025-69872 by restricting pickle deserialization to a hardcoded allowlist of safe built-in types. Arbitrary objects can no longer be deserialized from cache, preventing code execution via crafted pickle payloads.

Approach

This uses a SafeUnpickler with an allowlist-based find_class override — a fundamentally different approach to #361 (HMAC envelope). The key difference:

• HMAC (Mitigate CVE-2025-69872: HMAC-verified pickle envelope #361): still deserializes arbitrary types once the signature is valid. An attacker with read+write access to the cache directory can read the auto-generated key file and forge payloads.
• Allowlist (this PR): blocks dangerous types regardless of filesystem access. No key management, no env vars, no file creation.

What's allowed

int, float, str, bytes, bytearray, list, dict, tuple, set, frozenset, complex, range, slice, object, bool, None, collections.OrderedDict, collections.defaultdict, collections.deque, datetime.*, decimal.Decimal, fractions.Fraction, uuid.UUID

Everything else raises UnpicklingError on read.

Breaking change

This is intentionally a breaking change (version bumped to 6.0.0). Users caching custom types have two migration paths:

1. Use JSONDisk for JSON-serializable data
2. Subclass Disk and override get()/fetch() with a custom serializer

There is no opt-out by design — an escape hatch would just be cargo-culted by every downstream that hits an error.

Downstream compatibility

UnpicklingError inherits from pickle.UnpicklingError so libraries that catch pickle.PickleError (e.g. dvc-data's translate_pickle_error decorator) handle it gracefully.

Tests

• All 179 existing tests pass unchanged
• 26 new security tests covering: safe type round-trips, exploit blocking (os.system, eval, subprocess, __reduce__), cache integration, no-escape-hatch verification, FanoutCache/Deque/Index
• isort and blue pass

Fixes CVE-2025-69872
Closes #357, #360, #362

[a2811057970]

@grantjenks would appreciate a review when you get a chance. This is a minimal alternative to #361 for CVE-2025-69872 — 150 lines of additive code vs 1000+ lines, with stronger security guarantees (blocks dangerous types even if the attacker has full cache directory access).