billiard 4.3.2
- Source
- https://github.com/celery/billiard
- Artifact scanned
billiard-4.3.2-py3-none-any.whl- Compared with
billiard-4.3.1-py3-none-any.whl(0 signals introduced since)- Files
- 30 scanned, 3 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 5 info
- Scan time
- 6.0 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 5 of 5 warn and critical signals; 5 demoted to info.
- Disclude version
- 4.3.0
- Scanned (UTC)
- 2026-11-02 09:27
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
=likely benign os.popen runs a platform command to query the CPU count.Reasoning
This is a CPU-count probe that runs a fixed system utility (such as sysctl or getconf) and parses an integer from its output. The command comes from an internal constant, not from untrusted input, and the ValueError handler fits a numeric parse. The non-literal argument is a false positive from the static pattern.
-
passlikely benign __import__ loads a configured module name for forkserver preloading.Reasoning
The import sits in a try/except ImportError and is used to preload modules named in a list supplied by the multiprocessing configuration. Dynamic import of configured module names is a normal forkserver pattern, and nothing in the snippet is decoded or fetched from outside.
-
likely benign exec generates proxy method wrappers for exposed manager methods.
Reasoning
This is the standard multiprocessing manager idiom: it generates proxy method bodies from a fixed list of exposed method names, using %s and %r formatting. The exec input is developer-controlled and no untrusted data reaches it.
-
= = returnlikely benign exec builds synchronized ctypes property accessors from a template.Reasoning
This is the stdlib ctypes pattern for building synchronized property accessors from a fixed template, with the field name substituted in. The template is internal and the exec is not fed external input.
-
= =likely benign __import__ loads the main project module while preparing a spawned child process.Reasoning
The module is imported by name while the parent process prepares a spawned child, which is how multiprocessing spawn locates the __main__ project directory. The name comes from the running program's own main module, so this is expected behaviour.
Reproduce This Scan
Run disclude locally to verify. These commands scan the published file; the "new in this release" marks come from comparing it with the previous release's file, which they don't repeat. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.
|