xxhash 4.0.2
- Source
- https://github.com/ifduyue/python-xxhash
- Artifact scanned
xxhash-4.0.2.tar.gz- Compared with
xxhash-4.0.1.tar.gz(0 signals introduced since)- Files
- 27 scanned, 8 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 4 info
- Scan time
- 5.1 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 4 of 4 warn and critical signals; 4 demoted to info.
- Disclude version
- 4.3.0
- Scanned (UTC)
- 2026-10-23 09:42
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
|| /* WASM SIMD128 via SIMDe */likely benign Temporary #define of inline around an arm_neon.h include in the vendored xxHash header, a documented clang workaround.Reasoning
This is the standard xxHash header workaround that temporarily redefines inline around including arm_neon.h to work around a clang bug, then undefines it. It is a known legitimate compatibility pattern and not obfuscation; the raw macro-keyword pass flags it only because it touches a keyword.
-
;likely benign Two ordinary local variable names in xxHash's hashing routine collide under visual-skeleton normalization.Reasoning
The flagged identifiers bitflip1 and bitflip2 are ordinary variable names in the xxHash 9-16 byte path. The confusable collision is an artifact of the skeleton normalization (l/1 and i/l-like letters), not hidden code. The surrounding code is the standard published xxHash algorithm.
-
= =likely benign Build script execs the package's own version.py to read the VERSION string, a common packaging pattern.Reasoning
setup.py execs the contents of xxhash/version.py, a file shipped in the package itself, into a dict to read VERSION. This is a common packaging idiom for reading a version without importing the package. The exec runs at module scope in setup.py, which is typical for build scripts, and the target is a local, known file rather than network or encoded data. Still a dynamic exec, so some residual doubt remains.
-
= returnlikely benign Test helper dynamically imports an interpreter module by name and checks for a create function.Reasoning
This is a test helper that dynamically imports a module by name inside a try block and checks for a create attribute, likely to probe for available interpreter backends. The name comes from a test-controlled list, so this is a legitimate test pattern rather than malicious dynamic loading.
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.
|
&&