Dill

General Information

Field	Value
Package Name	dill
Manufacturer / Vendor	Mike McKerns / uqfoundation
Software Category	Library
Primary Documentation	Documentation, GitHub, PyPI
Programming Language(s)	Python
License	BSD 3-Clause
Deployed Version(s)	>=0.4.0 (version-locked at 0.4.0 in detection services)
Most Recent Available Version	0.4.1
Last Review Date	2026-01-27

Overview

Dill is a Python serialization library that extends the standard pickle module to handle a broader range of Python object types. The library enables serialization of "exotic" Python types that pickle cannot handle, including lambda functions, nested functions, closures, code objects, and modules. With over 2,400 GitHub stars and 236,000 dependent projects, dill is widely adopted in the scientific Python ecosystem, particularly in distributed computing and machine learning frameworks.

Within the medical device software, dill is an indirect dependency used exclusively by the Ultralytics YOLO object detection framework. It is not directly imported or invoked by the device's custom code. The specific usage context is:

• Detection expert module: The legithp-expert[detection] optional extra declares dill as a dependency alongside Ultralytics
• YOLO model serialization: Ultralytics internally uses dill to serialize and deserialize YOLO model checkpoints (.pt files) containing complex Python objects such as lambda functions, custom loss functions, and callback definitions that standard pickle cannot handle

Dill was included as a dependency because:

• Required by Ultralytics YOLO for model checkpoint serialization
• Handles complex Python objects (lambdas, closures) embedded in YOLO model architectures
• BSD 3-Clause license permits commercial use in medical device software

Functional Requirements

The following functional capabilities of this SOUP are relied upon by the medical device software (via Ultralytics).

Requirement ID	Description	Source / Reference
FR-001	Serialize Python objects to byte streams	dill.dumps() function
FR-002	Deserialize byte streams back to Python objects	dill.loads() function
FR-003	Handle lambda functions and closures during serialization	Extended pickle protocol for exotic types
FR-004	Maintain compatibility with standard pickle protocol	Pickle protocol levels 0–5
FR-005	Serialize code objects and nested functions	Support for types.CodeType objects

Performance Requirements

The following performance expectations are relevant to the medical device software.

Requirement ID	Description	Acceptance Criteria
PR-001	Model loading shall complete within service startup bounds	Deserialization does not dominate startup time
PR-002	Memory usage shall be bounded during deserialization	No memory leaks from repeated model loads

Hardware Requirements

The following hardware dependencies or constraints are imposed by this SOUP component.

Requirement ID	Description	Notes / Limitations
HR-001	Sufficient system memory for object graph	Memory scales with serialized object size
HR-002	x86-64 or ARM64 processor architecture	Pure Python; no platform-specific binaries

Software Requirements

The following software dependencies and environmental assumptions are required by this SOUP component.

Requirement ID	Description	Dependency / Version Constraints
SR-001	Python runtime environment	Python >=3.9 (device uses >=3.12)
SR-002	Setuptools for installation	Setuptools >=42
SR-003	Standard library pickle module	Bundled with Python

Known Anomalies Assessment

This section evaluates publicly reported issues, defects, or security vulnerabilities associated with this SOUP component and their relevance to the medical device software.

No CVEs or security vulnerabilities have been identified for dill. A comprehensive review of the following security databases was conducted on 2026-01-27:

• National Vulnerability Database (NVD) — no entries for "dill python"
• GitHub Security Advisories for uqfoundation/dill — no published advisories
• Snyk vulnerability database — no known vulnerabilities

However, dill shares the fundamental security characteristics of Python's pickle module: deserialization can execute arbitrary code. This is by design, as pickle-family libraries reconstruct Python objects including their methods and internal state. The dill documentation explicitly states: "it is left to the user to decide whether the data they unpickle is from a trustworthy source."

The device's usage pattern eliminates exposure to insecure deserialization risks:

• No external file loading: The device does not use dill to deserialize data from external or user-supplied sources
• Controlled model sources: YOLO model weights are pre-packaged, versioned, and retrieved exclusively from trusted internal storage (S3 buckets under organizational control)
• Indirect usage only: Dill is invoked internally by Ultralytics; the device code does not directly call dill.load() or dill.loads()
• Version locking: Requirements lock files pin dill to version 0.4.0, ensuring reproducible and auditable deployments
• Container isolation: Detection services run in isolated containers with restricted filesystem access
• No pickle from API inputs: The device API accepts only validated JSON and image data; no serialized Python objects are accepted from clients

Risk Control Measures

The following risk control measures are implemented to mitigate potential security and operational risks associated with this SOUP component:

• Version locking via requirements_lock.txt ensures reproducible, auditable deployments
• Model weights are loaded only from trusted, organization-controlled S3 storage
• No user-supplied or external pickle/dill data is ever deserialized
• Container isolation restricts filesystem access to required paths only
• The device does not use dill's load_module() or session-saving features
• Input validation at API boundaries rejects all non-JSON payloads

Assessment Methodology

The following methodology was used to identify and assess known anomalies:

• Sources consulted:

  • National Vulnerability Database (NVD) search for "dill python"
  • GitHub Security Advisories for uqfoundation/dill
  • Snyk vulnerability database and package advisor
  • PyPI package page
  • OWASP insecure deserialization guidance
  • Security research on pickle-based serialization vulnerabilities

• Criteria for determining applicability:

  • Vulnerability must affect deployed versions (dill 0.4.0)
  • Vulnerability must be exploitable through the device's operational context (controlled model loading, no external deserialization)
  • Attack vector must be reachable through the device's interfaces (no user-supplied serialized data)
  • Storage controls and container isolation must not already mitigate the vulnerability

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001