uv 0.13.4
- Source
- https://github.com/astral-sh/uv
- Tag scanned
0.13.4- Compared with
0.13.3(1 signals introduced since)- Files
- 1177 scanned, 652 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 119 info
- Scan time
- 71.2 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 80 of 80 warn and critical signals; 80 demoted to info.
- Disclude version
- 4.1.0
- Scanned (UTC)
- 2026-10-22 06:52
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
info
warn→ info by reviewdynamic-executiondocs/getting-started/installation.md:28:5new in this releaselikely benign Documentation showing a version-pinned uv install script command.Reasoning
Pinned-version variant of the official uv install script in documentation; legitimate and consistent with the project's install docs.
-
likely benign Smoke-test step invoking the project's own CLI by a variable name.
Reasoning
The flagged `${MODULE_NAME}` is a workflow-level variable naming the project's own CLI, used to run its `--help` smoke test after a local pip install. The pattern is a standard release-workflow check. The variable is defined elsewhere in the workflow, and the AST pass flags any variable command name even when it is harmless.
-
likely benign Smoke test running the project's own build-helper CLI by variable name.
Reasoning
Same pattern as the other build-release smoke tests: `${MODULE_NAME}-build --help` runs the package's own build helper after installing its freshly built wheel or sdist. Nothing here fetches or runs untrusted code.
-
likely benign Post-build verification step that installs and runs the project's own CLI.
Reasoning
This is a release-verification step that installs the just-built package from local dist/ with --no-index and runs its help command. The variable command name is the project's own module name, and the flag is a generic AST heuristic.
-
likely benign Local install and help smoke test of the built uv-build package.
Reasoning
The step installs the locally built uv-build distribution from a local directory with --no-index and smoke-tests it. This is ordinary build-verification behaviour with no remote code fetched at run time.
-
# Namespace runners do not include winget.likely benign Assignment of a pinned NASM version and SHA256 used to build a download path.Reasoning
This PowerShell step pins NASM version 3.02 and a SHA256 hash, then downloads the installer from the official nasm.us release path. The `$version` reference is string interpolation in a URL and filename, not a dynamic command. The pinned hash is the expected supply-chain control.
-
likely benign Constant assignment of the expected NASM installer SHA256.
Reasoning
The `$sha256` line is a constant string assignment that pins the expected installer hash. It is not executed as a command, so the finding is a false positive from the variable-command heuristic.
-
likely benign Builds a temp path for the NASM installer download.
Reasoning
The `$installer` path is built with Join-Path under RUNNER_TEMP and downloaded from the official NASM host. The variable is used as a file path for `-OutFile`, not as an executed command name, so the finding is a heuristic false positive.
-
if ()likely benign Silently runs the downloaded NASM installer and checks its exit code.Reasoning
`Start-Process $installer` runs the NASM installer that was downloaded from the official host, pinned by version and hash, with the silent `/S` flag, and the exit code is checked. The variable only holds the path to a known installer, so the execution is expected for a build dependency.
-
if ()likely benign Checks the NASM installer exit code and fails on error.Reasoning
This is an exit-code check after the NASM installer runs. The `$installation` variable is a process object, and the error throw is a normal failure guard, so nothing here is malicious.
-
if () |likely benign Adds the NASM install directory to the GitHub Actions PATH.Reasoning
The line appends the standard NASM install directory to GITHUB_PATH so later build steps can find the assembler. This is a routine CI PATH setup, and the variable is a process object, not an executed command name.
-
info
critical→ info by reviewdynamic-execution.github/workflows/build-release-binaries.yml:384:13IMPORTS_FILE="/-coff-imports.txt" if ; thenlikely benign Release workflow runs llvm-readobj to list COFF imports of a built Windows binary.Reasoning
LLVM_READOBJ is a tool path (llvm-readobj) set from a tool lookup in a release workflow; running it to dump COFF imports for a DLL-dependency check is a standard build verification step, not malicious. The flagged pattern is a variable command name, which is normal in CI.
-
likely benign Smoke test invoking the built package's module name with --help after pip install.
Reasoning
MODULE_NAME is a project-defined variable (the package's module name) used to smoke-test an installed wheel with --help. This is ordinary release-test scripting in a uv repository; the variable is set in workflow env, not from untrusted input.
-
likely benign Smoke test of the built uv-build package via its module/command name.
Reasoning
Same pattern as the other MODULE_NAME smoke tests: installs the built uv-build wheel and runs its help command. Routine CI verification with a workflow-defined variable.
-
likely benign Smoke test invoking the installed package command with --help.
Reasoning
Routine release smoke test running the installed package's command and module with --help; the variable is workflow-defined and no untrusted input flows into it.
-
likely benign Smoke test of the built uv-build package via its command name.
Reasoning
Routine release smoke test of the built uv-build wheel with workflow-defined variables; typical CI verification.
-
likely benign Smoke test invoking the installed package command with --help.
Reasoning
Same routine CI smoke test of the installed package's command and module with --help.
-
likely benign Smoke test of the built uv-build package via its command name.
Reasoning
Routine release smoke test of the built uv-build wheel; variable is workflow-defined.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME} --helplikely benign Smoke test invoking the installed package command with --help, with a TODO comment about platform coverage.Reasoning
Routine smoke test with a workflow-defined module name; the commented-out line is a TODO about platform support, not hidden behavior.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME}_build --helplikely benign Smoke test of the built uv-build package with a TODO about platform coverage.Reasoning
Routine release smoke test of the built uv-build wheel; the TODO comment concerns test coverage only.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME} --helplikely benign Smoke test invoking the installed package command with --help.Reasoning
Routine release smoke test with workflow-defined variables and a benign TODO comment.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME}-build --helplikely benign CI smoke test that runs the built package's CLI via a templated module name.Reasoning
The variable command name is a standard smoke-test step in a release workflow, where the module name is a workflow-defined value. The surrounding file is a normal CI pipeline for building uv binaries, and the snippet shows no decoding, remote fetching, or concealment. The flag comes from the generic variable-command rule.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME} --helplikely benign Release workflow step that invokes the freshly installed package's CLI with --help.Reasoning
This is the same release-workflow smoke test pattern: the templated command name runs the just-installed package's entry point to verify the build. Nothing in the snippet is hidden or malicious, and the flag reflects only the variable command name.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME}-build --helplikely benign Build-verification step running the installed build tool's --help via a templated name.Reasoning
The step installs a locally built wheel from /dist and checks its help output, which is ordinary build verification. The templated command is a workflow-defined name, not attacker-controlled input.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # .venv/bin/python -m ${MODULE_NAME} --helplikely benign Venv-based smoke test that runs the installed package's executable.Reasoning
The step installs the package into a local venv and runs its entry point, a routine smoke test in release CI. The variable is set by the workflow, and the snippet shows no obfuscation or external download.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here.likely benign Post-install check that runs the built tool's --help from a venv.Reasoning
This is a standard post-install verification step in a release pipeline, invoking the built tool's help command. The dynamic name is a workflow-level variable and the file shows typical CI behavior.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # .venv/bin/python -m ${MODULE_NAME} --helplikely benign Release test step that exercises the installed package's CLI.Reasoning
The templated command runs the package's CLI from a local venv after installing a wheel from /dist. This is routine release testing with no sign of malicious intent.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME} --helplikely benign Smoke test invoking the installed module's help output.Reasoning
Same smoke-test pattern: a local wheel install followed by a help invocation of the module, with the name supplied by the workflow. Nothing in the snippet is concealed or fetched remotely.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here.likely benign Venv install verification that runs the built tool's help command.Reasoning
Routine verification of a freshly built venv install in a release workflow. The dynamic command name is a workflow variable and the context is ordinary CI testing.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME}_build --helplikely benign Release CI step that checks the built package's help output.Reasoning
This is a standard build-verification step that runs the packaged CLI's help. The templated name is set by the workflow, and there is no encoding, network fetch of code, or evasion in the snippet.
-
|likely benign CI step that downloads and runs the hawk installer script from an official GitHub release.Reasoning
The pipeline downloads an installer script over HTTPS with TLS 1.2 enforced from the official astral-sh GitHub releases, pinned by a version variable, and runs it with sh. Piping an installer to a shell is risky in general, but this is a common vendor installation pattern with no obfuscation. The residual doubt is that the script itself is not visible.
-
if [; then comment=" An upstream pull request was already created at [#](https://github.com/astral-sh/uv/pull/)." fi marker="<!-- uv-promotion-rejection:: -->" -
if ; then elselikely benign A CI test loop executes uv or other test commands taken from a variable.Reasoning
The loop runs commands from a `$cmd` list that the test workflow itself supplies, a common pattern in test harnesses. The variable comes from the workflow's own test matrix, not from attacker-controlled input, and nothing in the snippet is encoded or hidden.
-
else filikely benign Else branch of the same CI test loop that runs a variable command.Reasoning
This is the else branch of the same test-runner loop over workflow-defined commands. It is ordinary CI test-runner behaviour with no obfuscation or malicious indicators.
-
# Call Python Install Manager's py.exe by full path to avoid legacy py.exe &dismissed PowerShell step invoking py.exe by full path to install Python 3.14.Reasoning
The `$env:` token is PowerShell environment-variable syntax in a Windows step, which the bash-oriented parser misreads as a command name. The line calls the Python Install Manager's py.exe by its full path, as the comment says.
-
if ! ; then -
if ! ; then -
likely benign Sources the Pyodide virtualenv's activate script after creating it.
Reasoning
The script sources the venv activate file that the same job just created with `uv venv -p ... $PYODIDE_VENV`. Sourcing a venv's activate script from a workflow-controlled path is standard practice.
-
&dismissed PowerShell activation of a native venv via a Windows backslash path.Reasoning
The flagged 'escapes' are ordinary Windows path backslashes in `.\venv-native\Scripts\Activate.ps1`, a normal venv activation. This is a parser artifact, not command hiding.
-
dismissed PowerShell step setting Pyodide environment variables for later CI steps.
Reasoning
The `$env:` assignments are PowerShell syntax for setting environment variables from `pyodide config` output and writing them to GITHUB_ENV. This is routine CI setup and the scanner misparses it.
-
dismissed PowerShell step exporting the Pyodide package index to GITHUB_ENV.
Reasoning
Same PowerShell `$env:` assignment and GITHUB_ENV export pattern as the adjacent lines. It is benign CI configuration, and the flag comes from parsing PowerShell as bash.
-
&dismissed Windows PowerShell step running uv to create a venv and install numpy.Reasoning
`.\uv.exe` with backslashes is a normal Windows relative executable path, and the rest of the snippet is a standard uv and pip install sequence. The escape count is a false positive from Windows paths.
-
# Add pyenv-win to PATH for this sessiondismissed PowerShell step adding pyenv-win directories to PATH for the session.Reasoning
This sets PYENV and PATH for pyenv-win in PowerShell, which is ordinary Windows toolchain setup. The `$env:` syntax is misread by the bash-oriented parser.
-
# Add to GITHUB_PATH so WSL can find the shimsdismissed PowerShell step extending PATH with pyenv-win shims.Reasoning
This is the same pyenv-win PATH setup as the preceding line, using PowerShell `$env:` syntax. It is benign build configuration.
-
& &dismissed PowerShell step installing and selecting Python 3.11.9 via pyenv-win.Reasoning
The command runs pyenv-win from the PYENV directory set earlier in the same job to install and select Python 3.11.9. This is routine toolchain setup, and the flag comes from parsing `$env:` as a command name.
-
& &dismissed PowerShell step setting the global pyenv-win Python version to 3.11.9.Reasoning
This is the second pyenv-win call in the same step, setting the global Python version. It is ordinary CI toolchain configuration with no hidden or encoded behaviour.
-
&dismissed PowerShell call to a pyenv-win binary under $env:PYENV in a Windows integration test workflow.Reasoning
The flagged line is PowerShell invoking pyenv-win from an environment variable path inside a CI test step. The bash-based parser misreads PowerShell's & call operator as a dynamic command name. No obfuscation or hostile behaviour is present.
-
likely benign eval of uv's self-generated bash completion script in a smoke test workflow.
Reasoning
eval runs the output of uv's own generate-shell-completion subcommand. This is the documented way to install shell completions and it executes the project's own trusted binary in CI.
-
likely benign eval of uvx's self-generated bash completion script in a smoke test workflow.
Reasoning
Same pattern as the preceding finding: eval of uv's own shell-completion output, a standard and trusted usage.
-
likely benign eval of uv self-generated completions in the smoke test workflow.
Reasoning
Identical snippet to the other smoke-test findings: eval of uv's own generated completion output in CI, which is benign.
-
likely benign eval of uvx self-generated completions in the smoke test workflow.
Reasoning
Identical snippet to the other smoke-test findings: eval of uvx's own generated completion output in CI, which is benign.
-
likely benign eval of uv self-generated completions in a repeated smoke test job.
Reasoning
Repeats the same benign eval of uv's own completion generator in another job of the same workflow.
-
likely benign eval of uvx self-generated completions in a repeated smoke test job.
Reasoning
Repeats the same benign eval of uvx's own completion generator in another job of the same workflow.
-
dismissed PowerShell PATH reset and invocation of check_system_python.py in a Windows system test.
Reasoning
PowerShell environment setup followed by a call to a repository script with an environment variable argument. The parser misreads the PowerShell line as bash, and the step is an ordinary CI check.
-
dismissed Passes $env:TEST_PYTHON_VERSION to check_system_python.py in a Windows system test.
Reasoning
Same PowerShell step as the preceding finding; the flagged column is just the $env:TEST_PYTHON_VERSION argument to a repository script in CI.
-
# Install pyenv | # Set up environment variables for current steplikely benign Installs pyenv by piping the official pyenv.run installer script to bash in a CI step.Reasoning
Piping a remote script to bash is a supply-chain risk pattern in general. Here it is the documented pyenv installer from its official domain, used in a CI test setup, so the concern is modest. Pinning or checksum verification would be better practice.
-
# Install Python 3.9likely benign eval of pyenv init output to set up the shell in a system test workflow.Reasoning
eval "$(pyenv init -)" is the standard pyenv shell setup recommended by its documentation. It runs the local pyenv binary's own init output in a CI test.
-
|dismissed PowerShell assignment capturing cargo bloat output in a Windows trampoline test.Reasoning
PowerShell variable assignment from a cargo bloat command, misparsed as a bash command name. The code only filters text output in CI.
-
| |dismissed PowerShell Select-String filtering of cargo bloat output in a Windows trampoline test.Reasoning
PowerShell pipeline filtering a variable with Select-String, misparsed as a bash command name. Ordinary CI logic with no execution of untrusted content.
-
| | if ()dismissed A PowerShell CI step that greps test output for panic or backtrace patterns and stores the match in a variable.Reasoning
The flagged variable $containsPatterns is only used as a condition in an if statement, not as a command name, so the 'command name is a variable' signal is a misreading of PowerShell. The step filters test output with Select-String, which is ordinary CI logic.
-
if ()dismissed The else branch of the same CI step, which exits with a failure code when unwanted output patterns are found.Reasoning
This is the same if-condition on $containsPatterns, followed by Exit 1. Nothing is executed dynamically, so the finding is a false positive.
-
# On macOS and Linux. |likely benign A README install instruction that pipes the uv install script from astral.sh into sh.Reasoning
The curl-to-sh installer is the standard documented install method for the uv tool, shown in user docs. It is a common supply-chain-sensitive pattern, but it is publicly documented and points to the project's own domain, so it is not hidden malicious behaviour.
-
dismissed IPA phonetic notation for the project name's pronunciation in the README.
Reasoning
The Latin and IPA characters in the pronunciation guide are legitimate phonetic notation, not identifier obfuscation, and the context is prose in a README.
-
dismissed IPA phonetic notation for the project name's pronunciation in the README.
Reasoning
The second IPA token is the same legitimate pronunciation notation in documentation prose.
-
<h1>Links for h1> <a href="/whl/Jinja2-3.1.2-py3-none-any.whl#sha256%3D4095ada29e51070f7d199a0a5bdf5c8d8e238e03f0bf4dcc02571e78c9ae800d">Jinja2-3.1.2-py3-none-any.a><br/> </body> </html>dismissed A test HTML page with a Jinja2 wheel link that carries a sha256 hash fragment.Reasoning
The blob is a sha256 hex digest in a URL fragment inside an HTML test fixture. It is not base64 content, and the pattern is an ordinary package index link.
-
1..=0x5e, r##"__import__("os").fsdecode(b"/foo/\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !\"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^/bar")"##, ),likely benign A Rust test table entry containing a Python bytes literal of control-character escapes for path decoding tests.Reasoning
The hex escapes build a byte string covering the full control-character range, used as a Python fsdecode test input for path-handling round trips. This is deliberate test fixture data, not a payload, and the code only constructs test strings.
-
0x5f..=0xa3, r#"__import__("os").fsdecode(b"/foo/_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3/bar")"#, ),likely benign A Rust test table entry with escaped high-byte values used to test path byte decoding.Reasoning
This is a systematic enumeration of byte values in a test table of Python fsdecode inputs. The pattern matches exhaustive edge-case testing and is not executed as an attack.
-
0xa4..=0xd1, r#"__import__("os").fsdecode(b"/foo/\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1/bar")"#, ),likely benign A test string with a sequential range of escaped bytes for path decoding tests.Reasoning
The escape run is a sequential byte range in a test string for the Python fsdecode path test. The surrounding code is a test table, so it is benign test data.
-
0xd2..=u8MAX, r#"__import__("os").fsdecode(b"/foo/\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff/bar")"#, ), ]likely benign The last test string in the path decoding table, covering the remaining high-byte range.Reasoning
This is the final sequential byte range in the same exhaustive path-decoding test table. It is benign test data.
-
/// the formatter out of line to avoid duplicating it at call sites. -
"space in middle", "alpha-α", ]; for input in failures -
assert_snapshot! -
@" Expected either `,` (separating extras) or `]` (ending the extras section), found `α` foo[bar α] ^ -
Expected either `,` or `]` , found `α` foo ^ " -
assert_snapshot! -
Expected one of `@`, ` -
assert_snapshot! -
assert_snapshot! -
@r#" Unexpected character 'α', expected 'and', 'or' or end of input foo; python_version == "3.12" αx ^^ -
Unexpected character 'α', expected 'and', 'or' or end of input foo; python_version == "3.12" αx ^^ "# -
Unexpected character 'α', expected 'and', 'or' or end of input foo; python_version == "3.12" αx ^^ "# -
-
-
@r#" Unexpected character 'α', expected end of input os_name == "nt" αx ^^ -
Unexpected character 'α', expected end of input os_name == "nt" αx ^^ "# -
Unexpected character 'α', expected end of input os_name == "nt" αx ^^ "# -
// Unicode "α", "férrîs", "안녕하세요", -
// Python implementations vary // https://github.com/pypa/pyproject-metadata/pull/150/files#diff-7d938dbc255a08c2cfab1b4f1f8d1f6519c9312dd0a39d7793fa778474f1fbd1L135-R141 let _ = writeln!; } -
"cGF0Cg==", "MTFBQlVDUjZBMERMUTQ3aVphN3hPdV9qQmhTMkZUeHZ4ZE13OHczakxuZndsV2ZlZjc2cE53eHBWS2tiRUFwdnpmUk8zV0dDSUhicDFsT01aago=", ];likely benign A test constant array of base64-encoded strings used as test fixtures in the uv test library.Reasoning
The values are base64 test fixtures, such as 'pat\n' and a token-like string. Test-suite constants like these are common and do not show obfuscated execution.
-
"cGF0Cg==", "MTFBQlVDUjZBMDJTOFYwMTM4YmQ0bV9uTXpueWhxZDBrcllROTQ5SERTeTI0dENKZ2lmdzIybDFSR2s1SE04QW8xTUVYQ1I0Q1YxYUdPRGpvZQo=", ];likely benign A second test constant array of base64-encoded strings in the uv test library.Reasoning
This is another base64 test fixture array with similar content, consistent with test data for credential or path handling.
-
ub const READ_ONLY_GITHUB_SSH_DEPLOY_KEY: &str = "LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0KYjNCbGJuTnphQzFyWlhrdGRqRUFBQUFBQkc1dmJtVUFBQUFFYm05dVpRQUFBQUFBQUFBQkFBQUFNd0FBQUF0emMyZ3RaVwpReU5UVXhPUUFBQUNBeTF1SnNZK1JXcWp1NkdIY3Z6a3AwS21yWDEwdmo3RUZqTkpNTkRqSGZPZ0FBQUpqWUpwVnAyQ2FWCmFRQUFBQXR6YzJndFpXUXlOVFV4T1FBQUlikely benign A base64-encoded read-only GitHub SSH deploy key constant used in the uv test library.Reasoning
The constant decodes to an OpenSSH private key, which is a credential-like blob. It is named as a read-only deploy key for test use, which is a plausible test fixture, but a committed key is worth noting as a secret-hygiene concern rather than evidence of malicious obfuscation.
-
// scripts, we can consider reverting https://github.com/astral-sh/uv/pull/5750/files#diff-969979506be03e89476feade2edebb4689a9c261f325988d3c7efc5e51de26d1L273-L277. canonicalize.unwrap_or_else -
let first = Named;dismissed Test fixture containing a PyPI wheel URL with a sha256 hash fragment.Reasoning
A base64-like string here is a long URL with a sha256 fragment in a Rust test fixture; the raw pass flags high-entropy-looking text in a URL and the compression ratio is ordinary for a hex-like hash. No decoding or execution occurs.
-
] sdist = wheels = -
] sdist = wheels = -
, ] "# -
, ] -
let requirements_in = context.temp_dir.child; requirements_in.write_str?; uv_snapshot! -
sdist = wheels = -
, ] -
sdist = wheels = -
, ] -
version = "2.0.0" archive = ----- stderr ----- -
hint: You're on , but `a` only has wheels for the following platform: `macosx_10_0_ppc64`; consider adding "sys_platform == '[PLATFORM]' and platform_machine == '[MACHINE]'" to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels "#); -
, , ] -
likely benign Documentation showing the official uv curl-to-sh install command.
Reasoning
This is the standard documented installer one-liner from the official uv project (astral.sh). Piping an install script to sh is a known pattern that is widely documented; the markdown context is prose showing a user command, not a hidden payload.
-
likely benign Documentation showing the wget variant of the uv install script.
Reasoning
Same official uv installer documented with wget; a legitimate install instruction from the project's own domain, not evidence of obfuscation.
-
likely benign Index page showing the official uv curl-to-sh install command.
Reasoning
Official uv installation command in the project index docs, same pattern as the installation guide; benign project documentation.
-
()dismissed Documentation example diffing pip list and uv pip list output.Reasoning
Shell example in docs comparing pip and uv pip lists using process substitution. The variable command name is a false positive from the markdown code block context; nothing is fetched or executed dangerously.
-
likely benign Documentation showing the uv install script invoked with --help.
Reasoning
Documented install command with --help flag from the project's own docs. Same benign curl-to-sh installer pattern; the flag is merely passed to the script for help output.
-
if [; then elselikely benign A bash wrapper script that execs either a user-configured REAL_CARGO binary or `cargo auditable` with the passed arguments.Reasoning
The exec targets $REAL_CARGO, an environment variable that the script checks, with a fallback to plain `cargo auditable`. This is a standard wrapper pattern that forwards arguments to the real cargo binary with the cargo-auditable subcommand. The dynamic path is a set-by-the-user override, not encoded or hidden code, and the snippet shows no download, decoding, or remote fetch. The flag is a generic dynamic-exec hit on a benign build helper.
-
CC=gcc else -
else -
# Make mold the default linker -
if [; then -
MANIFEST="artifacts/dist-manifest.json" assets=() while ;likely benign Release script invoking a helper script located relative to its own directory.Reasoning
Runs a sibling helper script from SCRIPT_DIR, which is derived from the script's own location in a release tooling repo. This is standard script-relative invocation, not an injection or dropper; the critical severity overstates it.
-
if ; then filikely benign Nextest setup hook invoking a repo-local codesign helper script.Reasoning
Calls codesign-macos.sh from SCRIPT_DIR with a test signing identity and target list. Ordinary test-harness tooling; the dynamic path resolves to a repo-local script, so this is expected behavior.
-
fi for; dolikely benign Release wheel test script running installed binaries from a venv.Reasoning
Invokes uv, uvx, uv-build from a virtual environment bin directory in a release-testing script. The variable comes from the script's own setup; the warning reflects the analyzer not seeing the assignment in this snippet.
-
for; dolikely benign Loop running uv, uvx and uv-build --help from a test virtual environment.Reasoning
Runs binaries from $virtual_environment/bin with a fixed loop list of names, all from a test venv the script created. Expected for release smoke testing; not a malicious dropper.
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.
&&