packaging 26.3
- Source
- https://github.com/pypa/packaging
- Tag scanned
26.3- Compared with
26.2(1 signals introduced since)- Files
- 105 scanned, 23 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 25 info
- Scan time
- 21.7 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 25 of 25 warn and critical signals; 25 demoted to info.
- Disclude version
- 4.0.0
- Scanned (UTC)
- 2026-10-14 18:08
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
info
warn→ info by reviewpayload-bytes-literaltests/test_requirements.py:954:5new in this release=likely benign Test fixture holding a serialized pickle of a packaging Requirement with prerelease handling.Reasoning
This is another pickle fixture for a packaging Requirement with prereleases, in the same test file and naming pattern as the other fixtures. The byte escapes are expected pickle encoding, and the bytes are only used as test input.
-
# -- General configuration ----------------------------------------------------likely benign Sphinx config executes the project's own __about__-style module to read version metadata.Reasoning
The exec reads the project's own src/packaging/__init__.py into a dict to pull out version metadata, a common Sphinx conf.py idiom. The path is built from the repository base directory, not from network or user input.
-
= flikely benign Validates a license expression by compiling it, a syntax check rather than execution.Reasoning
compile() is used only to validate a license expression syntactically and catches SyntaxError to report an error. Compiling in 'eval' mode does not execute the expression, so the risk is minimal.
-
likely benign Test build helper that runs a caller-supplied container command.
Reasoning
The script is a test helper where $1 is the container runtime command (for example docker or podman) passed in by the caller. This is a parameterized wrapper in test tooling, not a hidden payload.
-
likely benign Test helper that wraps an alpine container build with a caller-supplied runner.
Reasoning
Same pattern as the sibling function: $1 is the container runner chosen by the caller in a musllinux test build script. The command is a fixed docker run with known image names.
-
if ; thenlikely benign Dispatches to one of two local build helper functions by name.Reasoning
The dispatch to build_one_in_${1} selects one of the two local helper functions defined in the same file, so the target is bounded. The variable is a mode selector for a test matrix.
-
=likely benign Legacy pickle fixture of a packaging Marker object used in compatibility tests.Reasoning
This is a pickle byte fixture for backward-compatibility tests of packaging markers. The escaped bytes are the expected serialized output of older packaging versions, and the test compares it against unpickled objects. The high escape density is inherent to pickle data, not evasion.
-
=likely benign Versioned pickle fixture of a packaging Marker for regression tests.Reasoning
Another versioned pickle fixture for packaging marker compatibility tests, matching the expected output from an earlier packaging release. It is test data, not executed code.
-
=likely benign Pickle fixture for an older packaging Marker serialization in tests.Reasoning
This is a versioned pickle fixture for packaging marker regression tests. The payload only represents serialized packaging objects and is compared against expected results.
-
=likely benign Pickle fixture for a serialized packaging Requirement used in compatibility tests.Reasoning
This pickle fixture serializes a packaging Requirement and includes a c__builtin__ set reference, which is standard for pickle protocol 2 output of a set. It is used to test loading of old pickles. Pickle is a deserialization risk in production code, but here it is static test data. The verdict is not higher because pickle payloads deserve scrutiny.
-
=likely benign Versioned pickled Requirement fixture for requirements compatibility tests.Reasoning
Pickle fixture for a packaging Requirement, generated by the library's own serialization, with standard protocol-2 opcodes. It is static test data in a regression test and is not executed as a payload.
-
=likely benign Test fixture holding a serialized pickle of a packaging Requirement object.Reasoning
The snippet is a protocol-2 pickle byte string for a packaging Requirement object, the kind of fixture used to test unpickling compatibility across packaging versions. The payload-bytes-literal signal fires on the hex escapes that pickle output naturally contains. Nothing here executes at import time, and the file is a test module.
-
=likely benign Test fixture holding a serialized pickle of a packaging SpecifierSet.Reasoning
The snippet is a pickle of a packaging SpecifierSet, built from its internal _specs frozenset. It is a versioned compatibility fixture in a test module. The binary shape comes from pickle opcodes, not from concealed logic.
-
=likely benign Test fixture holding a serialized pickle of a packaging Specifier.Reasoning
This is a pickled packaging Specifier fixture with its _prereleases, _spec and related fields. It sits in the packaging test suite and is used to check that older pickles still load. The escapes are ordinary pickle data.
-
=likely benign Test fixture holding a serialized pickle of a packaging SpecifierSet.Reasoning
This is a pickled SpecifierSet fixture with internal state fields, the same style as the other versioned pickle fixtures in the test module. The byte content matches pickle serialization, and the bytes are only test input.
-
=likely benign Test fixture holding a serialized pickle of a packaging Specifier with range state.Reasoning
The snippet is a pickled packaging Specifier with _prereleases, _ranges and _spec fields, a compatibility fixture in a test file. The raw bytes are the expected output of pickle serialization.
-
=likely benign Test fixture holding a serialized pickle of a packaging SpecifierSet with internal flags.Reasoning
This is a pickled SpecifierSet with canonicalization and unsatisfiability flags, a versioned fixture in the packaging test suite. The escapes are pickle opcodes and length prefixes, not a hidden payload, and nothing executes them.
-
=likely benign Test fixture holding a nested serialized pickle of packaging SpecifierSet and Specifier objects.Reasoning
The snippet is a pickle of a nested SpecifierSet containing Specifier objects, used as a compatibility test input. The pattern is typical of serialized Python objects. There is no dropper pipeline or execution in the snippet.
-
=likely benign Test fixture holding a serialized pickle of a packaging Tag object.Reasoning
This is a pickled packaging Tag fixture with _abi, _hash and _interpreter fields in the test suite. The high escape ratio reflects binary pickle data including hash bytes. It is used only as test input.
-
=likely benign Pickle byte fixture of a packaging Tag object used in a test module.Reasoning
The bytes literal is a pickled packaging.tags.Tag object with ABI, interpreter and hash fields. It is a serialized test fixture for the packaging library's pickle compatibility tests, which explains the high escape density. The file is a test module and the content is consistent with that purpose.
-
=likely benign Second pickle byte fixture of a packaging Tag object in the test suite.Reasoning
Same pattern as the adjacent fixture: a pickled packaging.tags.Tag for cp39 with a hash field. It is a versioned test fixture for pickle round-tripping in the packaging test suite, with no execution or decoding logic in the snippet.
-
=likely benign Pickle byte fixture of a packaging Version object used in tests.Reasoning
The bytes encode a pickled packaging.version.Version object with a release tuple and attributes. This is a serialized fixture for version pickling tests. The snippet has no code that deserializes it in a dangerous way, and the file is a test module.
-
=likely benign Pickle byte fixture of a pre-release packaging Version object.Reasoning
A pickled Version object for a pre-release version string, consistent with the surrounding pickle compatibility fixtures. It is test data in a packaging library test file and is not used for code execution in the snippet.
-
=likely benign Pickle byte fixture of a packaging Version object with dev and epoch fields.Reasoning
Pickle opcodes encoding a Version with dev and epoch fields and a cache attribute. This is a serialization fixture for version compatibility tests in the packaging project, with no sign of malicious loading or execution.
-
=likely benign Pickle byte fixture of a complex packaging Version object with multiple segments.Reasoning
A pickled Version tuple with pre, post and dev segments, used to test pickle round-tripping of version parsing. It is a legitimate test fixture in the packaging test suite.
Reproduce This Scan
Run disclude locally to verify. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.
&&