disclude.iouv 0.13.5
- Source
- https://github.com/astral-sh/uv
- Tag scanned
0.13.5- Compared with
0.13.4(1 signals introduced since)- Files
- 1178 scanned, 654 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 119 info
- Scan time
- 68.7 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 12:30
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 curl-to-sh install command for uv.Reasoning
A versioned pin of the same official installer script, shown in project docs for reproducible installs.
-
likely benign Release-build CI step that runs the built package's CLI via a configured module name variable.
Reasoning
This is a release workflow that installs the freshly built package and smoke-tests its CLI with `${MODULE_NAME} --help`. The variable is a workflow-level value set by the repository's own CI config, not attacker-controlled input. The pass flagged a variable command name, which is normal in CI scripts and not obfuscation.
-
likely benign CI smoke test that runs the built uv-build helper using a repository-defined variable.
Reasoning
Same pattern as the other smoke-test steps: a repository-defined module name variable is used to run the just-built `-build` helper for a verification check. No external input or encoded payload is involved.
-
likely benign Release verification step that installs the local package and runs its CLI.
Reasoning
This is a repeated install-and-verify step in the release pipeline. It installs the package from a local dist directory and runs its CLI. The variable command name is repository-controlled, so the dynamic-execution flag is a false positive for CI scripting.
-
likely benign Release verification step for the uv-build package using local artifacts.
Reasoning
This is the uv-build variant of the install-and-smoke-test step. It installs from a local build directory and runs a repo-defined command name. No attacker-controlled input or obfuscation appears.
-
# Namespace runners do not include winget.likely benign Windows CI step that sets a pinned NASM version used to build a download URL.Reasoning
This is PowerShell in a Windows runner, not bash. The `$version` variable is a hardcoded pinned NASM version used to build a download URL. The pass misclassified the language. Pinning and downloading from the official nasm.us host is a standard build-dependency pattern.
-
likely benign Windows CI step that pins the expected SHA-256 of the NASM installer.
Reasoning
`$sha256` is a hardcoded checksum for the pinned NASM installer, which is a supply-chain integrity control and not a concealment technique. The flag comes from the PowerShell line being analyzed as bash. The snippet doesn't show the verification step, so a small doubt remains about whether the hash is actually checked.
-
likely benign Windows CI step that downloads the pinned NASM installer from the official site.
Reasoning
The step downloads the pinned NASM installer from the official nasm.us release path into RUNNER_TEMP. The flagged `$installer` variable is a local PowerShell path. This is a standard build-toolchain fetch, and the bash-language flag is a false positive.
-
if ()likely benign Windows CI step that silently installs NASM and checks the exit code.Reasoning
This runs the downloaded NASM installer silently with `/S` and checks the exit code. That is a normal unattended install in CI. The `$installation` variable is a PowerShell local, and the finding misreads the language.
-
if ()likely benign Windows CI step that aborts the build if the NASM installer fails.Reasoning
This is an exit-code check on the NASM installer process in PowerShell, which aborts the build if the install fails. It is ordinary error handling, and the flag is a language-misclassification false positive.
-
if () |likely benign Windows CI step that adds NASM's install directory to the runner PATH.Reasoning
This appends the NASM install directory to GITHUB_PATH so later steps can find the tools. It is a standard GitHub Actions pattern for toolchain setup, and the flagged variable is a PowerShell local, not an attacker-controlled command.
-
info
critical→ info by reviewdynamic-execution.github/workflows/build-release-binaries.yml:384:13IMPORTS_FILE="/-coff-imports.txt" if ; thenlikely benign CI step that runs llvm-readobj on a freshly built Windows binary to list its imports.Reasoning
This is the uv release workflow. LLVM_READOBJ is a tool path set from llvm tooling in CI and used to inspect a COFF import table of the just-built binary, which is a legitimate Windows CRT dependency check. The variable-command flag is a generic CI pattern, not a dropper.
-
likely benign Release smoke test invoking the built package's CLI via an env-provided module name.
Reasoning
Smoke-test step in a release workflow running the packaged module's --help after installing from local dist. MODULE_NAME is a workflow-set env value from the project's own build matrix; the variable command is a normal pattern for this kind of test.
-
likely benign Release smoke test for the uv-build wheel using a workflow-defined module name.
Reasoning
Same release smoke-test pattern for the uv-build package; the variable is a project-defined env value and the commands only run --help on locally built artifacts.
-
likely benign Release smoke test running the built package's --help via a workflow-defined variable.
Reasoning
Repeated release smoke test of the built package's CLI; no network fetch or untrusted input drives the command name.
-
likely benign Release smoke test for the uv-build package from local artifacts.
Reasoning
Release smoke test of the uv-build wheel from local dist; the variable is an internal CI configuration value.
-
likely benign Release smoke test invoking the built package's CLI.
Reasoning
Same release smoke-test pattern, running the built package's CLI from locally built artifacts with a project-defined module name.
-
likely benign Release smoke test for the uv-build wheel.
Reasoning
Smoke test of the uv-build wheel with local artifacts and a workflow-defined module name; 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 Post-install verification of the uv package's CLI in a release workflow.Reasoning
Release verification step testing the installed package's CLI. The variable is a CI-configured name, and the surrounding TODO comments show ordinary maintenance work.
-
# 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 Post-install verification of the uv-build package in a release workflow.Reasoning
Routine release verification of the uv-build package with locally built artifacts; the commented-out lines and TODO indicate normal project maintenance.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME} --helplikely benign Post-install verification of the package CLI in a release workflow.Reasoning
Same post-install smoke test pattern in a release workflow, running the package's own CLI with an internally configured module 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 CI smoke test that runs the built package's entry point via a MODULE_NAME variable.Reasoning
The command name comes from a workflow-level variable used to smoke-test a freshly built wheel's CLI. Expanding a variable in CI is a common pattern and the snippet has no sign of attacker-controlled input. The variable is defined elsewhere in the workflow, which the snippet does not show.
-
# 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 CI step invoking the installed package's CLI via a variable name.Reasoning
Same release-workflow smoke test pattern, running the installed package's command after a local pip install from /dist. The variable is a configured name, not external input, so this is ordinary build verification.
-
# 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 a variable-named CLI from the built wheel.Reasoning
Same pattern as the other release-build smoke tests: a variable-named command run after installing the locally built wheel. Nothing in the snippet indicates untrusted control of the value.
-
# 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 release smoke test executing the packaged CLI via a variable.Reasoning
A venv-based smoke test running the package's CLI through a variable name. This is routine CI verification of a release artifact.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here.likely benign Release CI check running the build helper's --help via a variable name.Reasoning
Routine release-workflow check that the installed build helper responds to --help. The variable comes from workflow configuration and the snippet shows no external data flow.
-
# 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 Smoke test of the installed package command in a release workflow.Reasoning
Same venv smoke-test pattern executing the packaged command by configured name. It is a normal verification step in a release pipeline.
-
# 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 CI invoking the installed CLI for a --help sanity check.Reasoning
Routine check that the freshly installed CLI runs, with the name supplied by workflow configuration. No sign of injection or hidden payload.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here.likely benign Release workflow sanity check of the build helper binary via a variable.Reasoning
Same release smoke-test pattern for the build helper, running a configured command name after a local wheel install. Benign build verification.
-
# 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 checking the build helper runs, with a configured command name.Reasoning
Final variant of the same release smoke test, checking the build helper's --help output. The variable is configuration-defined and the step is ordinary CI verification.
-
|likely benign CI step installing a pinned tool by piping the vendor's release installer script to sh.Reasoning
The step downloads an installer script over HTTPS with TLS 1.2 enforced from a versioned astral-sh GitHub release and pipes it to sh. Curl-to-shell is a risky pattern in general, but this is a common, pinned, first-party install method in a lint workflow, with no obfuscation or hidden logic.
-
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 Bash loop in a CI test workflow runs a command name taken from a variable.Reasoning
The variable command name is part of a loop over test commands in a CI workflow. The value is set by the workflow's own test matrix, not by an attacker-controlled source, and the branch that runs ./$cmd only applies to uv commands. This is a normal test-runner pattern.
-
else filikely benign Else branch of the same CI test loop executes the variable command.Reasoning
Same loop as the preceding finding: the else branch runs the command held in $cmd, which the workflow sets for ecosystem testing. Nothing in the snippet points to hidden or remote command selection.
-
# Call Python Install Manager's py.exe by full path to avoid legacy py.exe &dismissed PowerShell call to py.exe by full path in a Windows CI step.Reasoning
The flagged token is a PowerShell environment variable reference ($env:LOCALAPPDATA) used in a full path to py.exe. This is an ordinary Windows CI step that invokes the Python Install Manager, and the parser misread the PowerShell syntax as a bash variable command.
-
if ! ; then -
if ! ; then -
likely benign Sources the venv activate script at a variable path during Pyodide integration setup.
Reasoning
The workflow sources a virtualenv activate script whose path comes from the workflow's own $PYODIDE_VENV variable, which the job created earlier with uv venv. Sourcing a venv activate script is standard practice in CI.
-
&dismissed PowerShell activation of a relative venv script; backslashes are ordinary Windows path separators.Reasoning
The backslash count comes from a Windows relative path (.\venv-native\Scripts\Activate.ps1) and a PowerShell call, not from escaping that hides a command. The obfuscation signal misfires on normal Windows path syntax.
-
dismissed PowerShell environment variable assignment from pyodide config output.
Reasoning
This is a PowerShell $env: assignment that captures the output of pyodide config. The parser treated the $env: prefix as a variable command name. It is ordinary CI configuration.
-
dismissed PowerShell environment variable assignment for the Pyodide package index.
Reasoning
Same PowerShell $env: assignment pattern as the preceding line, setting the package index variable from pyodide config. No execution of untrusted content is present.
-
&dismissed Windows relative-path invocation of uv.exe and a venv activation script.Reasoning
The backslashes are Windows path separators in .\uv.exe and .\venv-pyodide\Scripts\Activate.ps1. The workflow runs its own uv binary and venv, so this is a parser artifact, not a hidden command.
-
# Add pyenv-win to PATH for this sessiondismissed PowerShell sets PYENV and PATH for a pyenv-win install in CI.Reasoning
This PowerShell line sets PYENV and PATH for a pyenv-win installation inside a CI job. The $env: references are normal PowerShell syntax, and the flagged 'variable command' is a misparse.
-
# Add to GITHUB_PATH so WSL can find the shimsdismissed PowerShell PATH update for pyenv-win shims in a Windows CI job.Reasoning
Same PowerShell PYENV and PATH setup as the preceding finding, here shown with the GITHUB_PATH comment. Standard CI environment configuration.
-
& &dismissed Invokes pyenv.bat from the workflow's PYENV directory to install Python 3.11.9.Reasoning
The line invokes pyenv.bat from the PYENV directory the workflow itself set up, to install and select Python 3.11.9. This is ordinary CI tooling; the $env: reference was misparsed as a variable command.
-
& &dismissed Sets the global pyenv-win Python version in a Windows CI step.Reasoning
Sets the global pyenv-win Python version after installation, in the same Windows CI step. Routine tooling setup with no sign of obfuscation or remote code.
-
&likely benign CI step that runs pyenv.bat versions to verify a pyenv-win install.Reasoning
The command is a PowerShell call to a pyenv-win binary under a path built from $env:PYENV, followed by a `versions` listing. This is a standard CI check that the installed tool works, with no download, decoding, or hidden behaviour.
-
likely benign Smoke test evaluates uv's own generated bash completion script.
Reasoning
The eval runs the output of the project's own built uv binary generating its shell completion script. This is a common, self-contained pattern in CLI test workflows and does not fetch remote code.
-
likely benign Smoke test evaluates uvx's own generated bash completion script.
Reasoning
Same eval of locally generated completion output from ./uvx, a self-generated script in a CI smoke test.
-
likely benign Smoke test evaluates uv's own generated bash completion script.
Reasoning
Repeated eval of the project's own generated completion script in another job, with the same benign context.
-
likely benign Smoke test evaluates uvx's own generated bash completion script.
Reasoning
Repeated eval of the project's own generated completion script, same benign context.
-
likely benign Smoke test evaluates uv's own generated bash completion script.
Reasoning
Repeated eval of the project's own generated completion script in another smoke job; benign.
-
likely benign Smoke test evaluates uvx's own generated bash completion script.
Reasoning
Repeated eval of the project's own generated completion script; benign.
-
likely benign CI step that resets PATH and runs a local system-Python check script.
Reasoning
PowerShell sets PATH from machine and user environment variables, then runs a repository check script with a version variable. The 'command name is a variable' warning is a parser artifact; the script is local and the behaviour is ordinary test setup.
-
likely benign Passes TEST_PYTHON_VERSION to the local check_system_python.py script.
Reasoning
Same line as the previous finding; the flagged $env:TEST_PYTHON_VERSION argument is passed to a local, repository-provided script, which is routine.
-
# Install pyenv | # Set up environment variables for current steplikely benign CI step installs pyenv by piping the pyenv.run installer into bash.Reasoning
This is the widely used pyenv installer piped to bash from its official domain. It is a real curl-to-shell pattern with supply-chain risk in general, but in a CI test setup it is the documented install method and nothing in the snippet is obfuscated or malicious.
-
# Install Python 3.9likely benign CI step evaluates the standard pyenv init output to set up shims.Reasoning
eval "$(pyenv init -)" is the standard documented pyenv shell initialization, evaluating pyenv's own output in a CI step.
-
|dismissed Assigns cargo bloat output to a variable and filters it with Select-String.Reasoning
$output is assigned the result of a `uv run cargo bloat` command and then piped to Select-String. The finding treats a variable assignment as a command, which is a parser misread of ordinary PowerShell; no execution of attacker-controlled data occurs.
-
| |dismissed Filters the cargo bloat output with a second Select-String for expected patterns.Reasoning
Assigns a pipeline filtered from the previous line's output to a variable. Again a parser false positive on normal PowerShell assignment, not dynamic execution.
-
| | if ()dismissed A PowerShell CI step that greps command output for patterns and branches on the result.Reasoning
The flagged `$containsPatterns` is a PowerShell variable used in an `if` condition, not a command name. The scanner misread the PowerShell syntax as embedded bash command execution. Nothing here runs attacker-controlled input.
-
if ()dismissed A PowerShell CI conditional that exits with status 1 when unwanted patterns appear in test output.Reasoning
Same PowerShell `if ($containsPatterns)` construct followed by `Exit 1`. It is a normal test-failure check in a CI workflow.
-
# On macOS and Linux. |likely benign The README's documented curl-to-sh install command for the uv tool.Reasoning
This is the official uv installer one-liner documented in the README. Piping a vendor install script to sh is a known, if debatable, distribution practice, and the URL points at the project's own domain. It is not obfuscation or a dropper hidden in the code.
-
dismissed IPA pronunciation notation in the README for how to say the project name.
Reasoning
The raw pass flagged IPA phonetic symbols in a pronunciation guide. This is legitimate Unicode text, not an identifier or obfuscation.
-
dismissed IPA pronunciation notation in the README for how to say the project name.
Reasoning
Same IPA pronunciation text as the previous finding; mixed-script flags on IPA characters in prose are false positives.
-
<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 An HTML test fixture linking to a Jinja2 wheel with a sha256 fragment.Reasoning
The 'blob' is a hex SHA-256 digest in a URL fragment inside an HTML test fixture for a package index page. It is a plain checksum, not an encoded payload.
-
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")"##, ),dismissed A Rust test case containing a Python snippet with all byte values escaped, used to test path decoding.Reasoning
The escapes form a Python byte-string literal in a Rust test table covering path-to-bytes round-trip cases. Byte-escape tables are normal for testing filesystem path encoding.
-
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")"#, ),dismissed A Rust test fixture enumerating byte values as Python fsdecode input.Reasoning
This is a systematic test table of byte values for path-decoding edge cases. The escapes are part of a fixture, not hidden logic.
-
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")"#, ),dismissed A Rust test fixture covering high-range bytes for path decoding.Reasoning
A consecutive byte-range table in a Rust test for path encoding. Enumerating non-ASCII bytes is expected for this kind of test.
-
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")"#, ), ]dismissed A Rust test fixture covering the final byte range for path decoding.Reasoning
Same systematic byte-range test fixture as the neighboring findings; it exercises edge-case bytes for path handling.
-
/// 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 Rust test table of base64-encoded credential-like fixture values.Reasoning
These are base64 strings in a test-data array, one decoding to 'pat' and others to short strings. They look like fixture values for credential-handling tests rather than an executed payload. Test context is not shown, so some doubt remains.
-
"cGF0Cg==", "MTFBQlVDUjZBMDJTOFYwMTM4YmQ0bV9uTXpueWhxZDBrcllROTQ5SERTeTI0dENKZ2lmdzIybDFSR2s1SE04QW8xTUVYQ1I0Q1YxYUdPRGpvZQo=", ];likely benign A base64 fixture in a Rust test table for credential-handling tests.Reasoning
Another base64 fixture from the same test table. The value is consistent with a fake token or test string used in authentication tests. No execution path is visible in the snippet.
-
ub const READ_ONLY_GITHUB_SSH_DEPLOY_KEY: &str = "LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0KYjNCbGJuTnphQzFyWlhrdGRqRUFBQUFBQkc1dmJtVUFBQUFFYm05dVpRQUFBQUFBQUFBQkFBQUFNd0FBQUF0emMyZ3RaVwpReU5UVXhPUUFBQUNBeTF1SnNZK1JXcWp1NkdIY3Z6a3AwS21yWDEwdmo3RUZqTkpNTkRqSGZPZ0FBQUpqWUpwVnAyQ2FWCmFRQUFBQXR6YzJndFpXUXlOVFV4T1FBQUlikely benign A Rust test constant containing a base64-encoded fake SSH deploy key.Reasoning
The base64 decodes to an OpenSSH private key header, which is a common test fixture for SSH deploy-key handling. It is named READ_ONLY_GITHUB_SSH_DEPLOY_KEY in a test crate, so it is most likely a dummy key. A real leaked key would be a concern, but nothing in the snippet suggests it is live or executed.
-
// scripts, we can consider reverting https://github.com/astral-sh/uv/pull/5750/files#diff-969979506be03e89476feade2edebb4689a9c261f325988d3c7efc5e51de26d1L273-L277. canonicalize.unwrap_or_else -
let first = Named;likely benign A test fixture URL containing a wheel path and sha256 hash fragment.Reasoning
The blob is a sha256 fragment inside a test URL for a real PyPI wheel, in a requirement-parsing unit test. It is data in a test fixture, not an encoded payload.
-
] 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 curl-to-sh install command for uv.
Reasoning
This is the documented official install command for uv (curl piped to sh). It is standard install guidance in project docs, and the pipe is the upstream installer convention.
-
likely benign Documentation showing the official wget-to-sh install command for uv.
Reasoning
Same documented official installer, shown with wget. It is standard install instructions in project docs.
-
likely benign Project homepage showing the official curl-to-sh install command.
Reasoning
The homepage repeats the official installer one-liner. This is normal documentation for the project's own install script.
-
()likely benign A console example running diff with process substitution to compare pip and uv package lists.Reasoning
The flagged token is a diff command in a console transcript comparing pip and uv listings. The $diff variable is an artifact of the markdown parser, and the snippet shows only ordinary tabular output.
-
likely benign Documentation showing the official installer piped to sh with a help flag.
Reasoning
Documented official installer invoked with -s -- --help to show options. It is ordinary install docs.
-
if [; then elselikely benign A cargo wrapper script that delegates to cargo auditable, optionally via an overridden cargo binary.Reasoning
This is a small wrapper that execs cargo auditable, using REAL_CARGO from the environment when set and falling back to cargo otherwise. It is a developer tooling shim with no download or decoding, though the env-driven exec path is a minor doubt.
-
CC=gcc else -
else -
# Make mold the default linker -
if [; then -
MANIFEST="artifacts/dist-manifest.json" assets=() while ;likely benign A release script invoking a sibling helper located via SCRIPT_DIR.Reasoning
SCRIPT_DIR is the usual self-location idiom, and the script runs a sibling helper in the same repository. This is normal release tooling.
-
if ; then filikely benign A nextest setup hook calling a sibling codesign script for test binaries.Reasoning
SCRIPT_DIR is set by the standard self-location idiom, and the call runs a sibling codesign helper for test binaries. This is ordinary test infrastructure.
-
fi for; dolikely benign A release test script running installed binaries with --help after pip install.Reasoning
The variable command comes from a Python interpreter array in a release-verification script. The caller sets the environment by design, and the script only runs --help checks on installed tools.
-
for; dolikely benign A loop running the freshly installed uv binaries from a test virtualenv with --help.Reasoning
The loop runs uv, uvx, and uv-build from a virtual environment created by the same script, with --help as the only argument. The binary names are fixed, so the runtime resolution is expected.
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.
&&