disclude.iouv 0.13.2
- Source
- https://github.com/astral-sh/uv
- Tag scanned
0.13.2- Compared with
0.13.1(1 signals introduced since)- Files
- 1175 scanned, 652 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 1 warn · 117 info
- Scan time
- 73.6 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 80 of 80 warn and critical signals; 79 demoted to info.
- Disclude version
- 4.0.0
- Scanned (UTC)
- 2026-10-20 11:12
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
# Install pyenv | # Set up environment variables for current stepsuspicious CI step installs pyenv by piping the pyenv.run installer to bash.Reasoning
curl piped to bash to install pyenv is the upstream-documented installer, which is a supply-chain risk in general but common in CI test setup and not obfuscation. Flagged as a pipeline into bash; the risk is real but this is a typical test-environment install from a well-known source.
-
info
warn→ info by reviewdynamic-executiondocs/getting-started/installation.md:28:5new in this releaselikely benign Documentation showing a version-pinned curl-to-sh uv install command.Reasoning
Documents a version-pinned uv install script from astral.sh. Standard documentation for a pinned installer.
-
likely benign Release workflow smoke test that invokes the package's own CLI via a templated module name.
Reasoning
The flagged line runs ${MODULE_NAME} as a smoke-test command in a release workflow. The variable is a project-defined name for the package's own CLI, and the surrounding steps are ordinary install-and-verify commands. The pattern is a generic dynamic-command heuristic firing on templated CI shell, not obfuscation.
-
likely benign Post-install smoke test in a release workflow that runs the project's own build-tool CLI.
Reasoning
Same pattern as the other workflow findings: ${MODULE_NAME}-build is the project's own build-tool CLI, invoked for a --help smoke test after a local pip install of a freshly built artifact. No external input controls the command name.
-
likely benign CI verification step that runs the package's CLI with --help after a local install.
Reasoning
The flagged command is ${MODULE_NAME} --help in a release-build CI job, run after installing the project's own package from a local dist directory. This is a routine verification step and the variable is set by the project's workflow.
-
likely benign Release pipeline smoke test of the uv-build CLI after a local install.
Reasoning
The line runs the project's build-tool CLI with --help after installing a locally built wheel. This is routine release-pipeline verification, and the command name comes from the project's own configuration.
-
# Namespace runners do not include winget.likely benign Windows CI step that downloads and installs a pinned NASM release from its official host.Reasoning
This is a PowerShell step that downloads the NASM installer from the official nasm.us host at a pinned version, and it defines a SHA-256 for verification. The flag is only that $version is interpolated into a command position by the generic heuristic. The pinned hash suggests integrity checking, though the verification line is not shown in the snippet.
-
likely benign Pinned SHA-256 constant for the NASM installer download in a Windows CI step.
Reasoning
$sha256 is a hardcoded hash constant for the pinned NASM installer. Its appearance here is a variable assignment, and the heuristic is misreading it as a command position. This is a benign supply-chain pin.
-
likely benign Computes the temp path for the downloaded NASM installer in a Windows CI step.
Reasoning
The line builds a path in RUNNER_TEMP for the NASM installer, which is then downloaded from the official nasm.us release URL. The variable only holds a file path, and the download is a normal build-dependency setup step.
-
if ()likely benign Runs the NASM silent installer and checks its exit code in a Windows CI step.Reasoning
$installation holds the result of Start-Process running the NASM installer with silent flag /S and -Wait. It then checks ExitCode and throws on failure. This is standard installer handling for a pinned, downloaded dependency in CI.
-
if ()likely benign Exit-code check after the NASM installer run in a Windows CI step.Reasoning
The flagged line is an exit-code check on the NASM installer result. Its only effect is to throw if installation fails, which is a normal error-handling pattern.
-
if () |likely benign Adds the NASM install directory to GITHUB_PATH for subsequent CI steps.Reasoning
The line appends the standard NASM install directory to GITHUB_PATH so later steps can find the assembler. This is ordinary CI PATH setup with no hidden execution.
-
info
critical→ info by reviewdynamic-execution.github/workflows/build-release-binaries.yml:384:13IMPORTS_FILE="/-coff-imports.txt" if ; thenlikely benign Release-workflow step that dumps COFF imports of a built Windows executable using an LLVM tool path resolved at runtime.Reasoning
The command runs $LLVM_READOBJ, a variable assigned from another command, to inspect COFF imports of a freshly built Windows binary, then greps for CRT DLL names. This is a standard way to locate an LLVM tool in a release pipeline. The variable is set in the same workflow, and the dependency it implies is not hidden or encoded. Remaining doubt: the assignment itself is not shown.
-
likely benign Smoke test that runs the installed package's console script and its python -m entry point with --help.
Reasoning
In a release-test step, ${MODULE_NAME} is the console-script name of the package just built and installed with pip from local dist/. Running its --help verifies the installed artifact. The variable is a workflow-level value, not attacker input, and the pattern is routine in packaging CI.
-
likely benign Post-install smoke test of the uv-build wheel's console script and module entry point.
Reasoning
This is the uv-build smoke test. It installs the locally built wheel and runs the console script derived from MODULE_NAME with --help. This verifies the release artifact, which is the normal purpose of such a step.
-
likely benign Install-and-verify step that runs the packaged tool's console script with --help.
Reasoning
Same smoke-test pattern as the other install-and-run steps in the release workflow. It installs a local wheel and checks the entry point with --help, and the variable comes from the workflow's own configuration.
-
likely benign Install and --help check of the uv-build wheel's entry points in another release job.
Reasoning
Repeats the uv-build wheel install and --help smoke test in another job. It has no network fetch, decoding, or privilege-related behavior. The variable is an internal name derived from the package.
-
likely benign Verification step that installs the built package and runs its console script with --help.
Reasoning
This is the same install-from-dist then run-entry-point verification pattern. It is consistent with release testing and does not involve untrusted input.
-
likely benign Post-install check of the uv-build console script and module entry point.
Reasoning
A smoke test for the uv-build wheel after installing it from local artifacts. The command name comes from the package name and is not user-controlled.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME} --helplikely benign Install-and-run smoke test of the packaged tool inside a platform test matrix.Reasoning
Installs the release wheel from /dist and runs its console script with --help. The surrounding TODO comment shows this is ordinary test maintenance, 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 Platform-matrix smoke test for the uv-build wheel's console script.Reasoning
Installs the uv-build wheel from /dist and runs the derived console script with --help, with a comment about platform test coverage. This is routine release validation.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME} --helplikely benign Matrix smoke test that runs the installed package's console script with --help.Reasoning
Same installed-package smoke test as the other matrix entries. The variable names the package's own script and nothing in the snippet suggests attacker-controlled input or remote code fetching.
-
# 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 Workflow runs the freshly installed package's CLI via a variable name for a --help smoke test.Reasoning
The command name comes from ${MODULE_NAME}, a workflow-level variable in a release build workflow that tests the just-built package's CLI. This is a normal way to parametrize a matrix job, and the snippet shows no attacker-controlled input or download path.
-
# 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 invokes the built package's entry point through a variable for a --help check.Reasoning
Same pattern as the other finding: ${MODULE_NAME} is a workflow-defined variable used to smoke-test an installed package from /dist. The surrounding commands are a standard build-and-verify sequence 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}-build --helplikely benign CI smoke-test of an installed build artifact via a workflow-defined command name.Reasoning
The variable command name is used to verify an installed build artifact in a release workflow. The snippet matches legitimate CI testing and contains no obfuscation.
-
# 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 workflow checks an installed venv binary by running it with --help.Reasoning
The venv-relative command is built from ${MODULE_NAME} in a release workflow that installs the package from local /dist and runs --help. This is ordinary packaging verification.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here.likely benign Build workflow runs a venv-installed tool with --help using a variable name.Reasoning
The variable command name is a standard way to exercise the installed package in a release job, and the snippet contains no untrusted input or remote code.
-
# 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 verification step invokes the installed package binary via a variable.Reasoning
This is the same local install-and-verify step with a workflow variable as the command name. Nothing in the snippet suggests malicious behavior.
-
# 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 pipeline smoke test of the installed package CLI.Reasoning
The step installs the built wheel from /dist and runs its CLI with --help. The variable is a workflow-level setting, consistent with a release pipeline test.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here.likely benign Verifies an installed build-tool binary with --help in a release workflow.Reasoning
The variable-named command is run after installing the local build artifact. This is typical packaging verification and matches the rest of the workflow.
-
# 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 workflow smoke test of a locally installed build package.Reasoning
The step installs the local build package and runs its entry point with --help. The variable command name is set by the workflow, and the commented-out alternative shows it is a deliberate test step.
-
|likely benign CI step downloads a versioned installer script from GitHub releases and pipes it to sh.Reasoning
A curl with enforced HTTPS and TLS 1.2+ fetches an installer script from a GitHub release of the same organization, using a version variable. Piping to sh is a known supply-chain risk, but this is the standard cargo-dist style installer pattern for a trusted project and shows no obfuscation.
-
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 a command taken from a variable, choosing between a local ./uv binary and a PATH command.Reasoning
The variable $cmd is branched on with a uv-prefix check and runs a locally built or PATH command. This is a test-matrix runner in a CI workflow, and the command is supplied by the workflow's own configuration, so this is a common test-harness pattern rather than a dropper.
-
else filikely benign The else branch of the same CI test loop runs the variable command directly.Reasoning
This is the else branch of the same $cmd dispatch loop. It runs the matrix-supplied test command and shows no download, decode, or pipe behaviour.
-
# Call Python Install Manager's py.exe by full path to avoid legacy py.exe &dismissed A PowerShell step calls py.exe by full path to install Python 3.14.Reasoning
In PowerShell, $env:LOCALAPPDATA is an environment-variable reference used inside a quoted path, not a command name. The analyzer misread the PowerShell env drive syntax as a variable command. The line invokes py.exe by full path to install Python.
-
if ! ; then -
if ! ; then -
likely benign A CI step activates a Pyodide virtualenv it just created by sourcing its activate script.
Reasoning
The script sources the activate script of a virtualenv that it just created in the same step, from a path built from the workflow's own variables. Sourcing a venv activate script is routine in CI.
-
&dismissed A PowerShell step activates a Windows venv via a relative backslash path.Reasoning
The flagged token is a Windows relative path to a venv Activate.ps1 script. Backslashes are path separators in PowerShell, not escape obfuscation.
-
dismissed A PowerShell step stores pyodide configuration values in environment variables.
Reasoning
The $env: prefix is PowerShell syntax for assigning an environment variable, and the line only captures output from pyodide config. The analyzer treated the variable as a command name.
-
dismissed A PowerShell step sets PYODIDE_INDEX and exports it to GITHUB_ENV.
Reasoning
This is the same PowerShell environment-variable assignment pattern. It sets PYODIDE_INDEX from pyodide config and writes it to GITHUB_ENV, which is a standard way to pass values between steps.
-
&dismissed A PowerShell step runs the local uv.exe to build a Pyodide venv and install numpy.Reasoning
The token is the relative path .\uv.exe, a Windows binary in the working directory. The backslashes are ordinary path separators, and the line runs uv to create a venv and install numpy.
-
# Add pyenv-win to PATH for this sessiondismissed A PowerShell step sets the PYENV environment variable to the pyenv-win install path.Reasoning
The $env: syntax is a PowerShell environment-variable assignment that builds a pyenv-win path from USERPROFILE. The analyzer mistook the env drive reference for a command name.
-
# Add to GITHUB_PATH so WSL can find the shimsdismissed A PowerShell step prepends pyenv-win directories to PATH.Reasoning
This line prepends the pyenv-win bin and shims directories to PATH using PowerShell environment syntax. It is a standard setup step with no download or decode.
-
& &dismissed A PowerShell step uses pyenv-win to install Python 3.11.9.Reasoning
The call invokes pyenv.bat through a path built from the PYENV variable to install a known Python version. The flagged $env is PowerShell env-variable syntax, not a hidden command.
-
& &dismissed A PowerShell step sets pyenv-win's global Python version to 3.11.9.Reasoning
This line sets the global pyenv Python version to 3.11.9 using the pyenv.bat path. It is ordinary CI environment setup with a pinned version.
-
&likely benign CI step invoking the pyenv-win binary via an environment-variable path to print versions.Reasoning
The flagged line runs pyenv-win from the PYENV environment variable path in a CI verification step. This is the standard pattern of a Windows CI workflow installing and checking a tool; the "variable command name" is just the install root. Benign.
-
likely benign CI smoke test evals uv's generated bash completion script.
Reasoning
eval on output of the project's own uv binary generating shell completions is a common documented install pattern. The source is a locally built or downloaded trusted tool in the repo's own CI, not untrusted input. Flagged as eval of a dynamic expression, but it's benign in context.
-
likely benign CI smoke test evals uvx's generated bash completion script.
Reasoning
Same as the adjacent finding: eval of the uvx completion generator output from the repository's own binary in a test workflow. Benign CI pattern.
-
likely benign Smoke test job evals uv completion output.
Reasoning
Repeated eval of the project's own uv/uvx completion generation in another job of the same smoke workflow. Benign.
-
likely benign Smoke test job evals uvx completion output.
Reasoning
Repeated eval of the project's own uv/uvx completion generation. Benign.
-
likely benign Smoke test job evals uv completion output.
Reasoning
Repeated eval of the project's own uv/uvx completion generation in another smoke job. Benign.
-
likely benign Smoke test job evals uvx completion output.
Reasoning
Repeated eval of the project's own uv/uvx completion generation. Benign.
-
likely benign Windows CI step adjusting PATH and running a repo check script.
Reasoning
PowerShell step that sets PATH from machine and user environment variables and runs a repo Python script with a parameter. The variable-as-command pattern is a PowerShell artifact of the scanner, not malicious. Benign.
-
likely benign Windows CI step passing an env var as a parameter to a repo script.
Reasoning
Same PowerShell step as the previous finding; the flagged $env reference is just a parameter value. Benign.
-
# Install Python 3.9likely benign CI step evals pyenv init output to set up shims.Reasoning
eval of pyenv init output is the standard documented shell setup for pyenv in a CI test job. Benign, though it is an eval of a dynamic expression.
-
|likely benign PowerShell step capturing cargo bloat output into a variable.Reasoning
PowerShell variable assignment ($output from running cargo bloat) flagged because the scanner misreads a variable as a command name. Benign.
-
| |likely benign PowerShell step filtering cargo bloat output with Select-String.Reasoning
PowerShell pipeline filtering captured output with Select-String. The flag is a parsing artifact of the variable name. Benign.
-
| | if ()dismissed A PowerShell CI step that filters test output with Select-String and fails if it matches unwanted patterns.Reasoning
The snippet is PowerShell, not bash. `if ($containsPatterns)` is a conditional test on a variable, not a command invocation, so the 'variable command name' signal is a misreading of the embedded script. The Select-String filters only inspect test output for panic or backtrace text.
-
if ()dismissed The else/exit branch of the same PowerShell output-check step.Reasoning
Same PowerShell snippet as the previous finding. The `if` tests a variable and runs `Exit 1` on match, which is ordinary CI control flow with no dynamic execution.
-
# On macOS and Linux. |likely benign Documentation of the official curl-pipe-sh installer for uv on macOS and Linux.Reasoning
This is the standard uv installation one-liner in the project README, a widely documented install method from the project's own domain. Piping an install script to sh is a known convention, though it does carry the usual trust-the-host risk. In a README it is documentation, not a dropper.
-
dismissed IPA pronunciation notation in the README's naming section.
Reasoning
The characters are IPA phonetic symbols in a pronunciation guide (/juː viː/). Mixed Latin and IPA script is expected in linguistic text and is not an identifier-level obfuscation.
-
dismissed Second IPA token in the same pronunciation guide.
Reasoning
Same IPA pronunciation text as the previous finding. The 'viː' token is the second word of the IPA transcription, which is legitimate documentation.
-
<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 sha256 hash fragment in a simulated package index HTML test fixture.Reasoning
The flagged 66-byte string is the hex sha256 digest in a URL fragment inside a test HTML fixture for a package index page. Hex digests are not base64 payloads, and the blob is ordinary test data.
-
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 test case feeding all low byte values as escaped bytes into os.fsdecode.Reasoning
The file is a Rust test table of Python snippets that exercise os.fsdecode on byte paths. The escape sequences enumerate every byte value for a round-trip test, which explains the high escape density and entropy. It is test data, not a payload.
-
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 sequential byte-range escape test case in the fsdecode test table.Reasoning
This is part of the same byte-enumeration test table for Python fsdecode. The escapes cover a contiguous byte range in the expected way for a surrogate-escape or encoding test.
-
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 byte-range escape test case in the fsdecode test table.Reasoning
The consecutive \xNN escapes enumerate a contiguous byte range inside a test table of Python fsdecode inputs. The pattern is systematic and matches a deliberate test matrix, not hidden code.
-
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 high-byte range case in the fsdecode byte-path test table.Reasoning
This is the final byte-range case in the same test table. The sequence covers the upper byte values, consistent with exhaustive testing of path byte 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 Base64-encoded test string constants in a uv-test helper.Reasoning
The array holds short base64 strings in a test helper. Decoded, they are simple text values such as 'pat' and a short token-like string. This looks like redaction or filter test data, and the flagged blob is not executed.
-
"cGF0Cg==", "MTFBQlVDUjZBMDJTOFYwMTM4YmQ0bV9uTXpueWhxZDBrcllROTQ5SERTeTI0dENKZ2lmdzIybDFSR2s1SE04QW8xTUVYQ1I0Q1YxYUdPRGpvZQo=", ];likely benign Another base64 test-constant array in the uv-test library.Reasoning
Same pattern: a base64 string array in test code whose values decode to plain test text. The surrounding code is a test fixture and nothing decodes and executes it.
-
ub const READ_ONLY_GITHUB_SSH_DEPLOY_KEY: &str = "LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0KYjNCbGJuTnphQzFyWlhrdGRqRUFBQUFBQkc1dmJtVUFBQUFFYm05dVpRQUFBQUFBQUFBQkFBQUFNd0FBQUF0emMyZ3RaVwpReU5UVXhPUUFBQUNBeTF1SnNZK1JXcWp1NkdIY3Z6a3AwS21yWDEwdmo3RUZqTkpNTkRqSGZPZ0FBQUpqWUpwVnAyQ2FWCmFRQUFBQXR6YzJndFpXUXlOVFV4T1FBQUlikely benign A base64-encoded read-only SSH deploy key constant in the uv-test library.Reasoning
The constant base64-decodes to an OpenSSH private key block. That is credential-shaped material committed to source, which warrants review, but it is named as a read-only deploy key used in test setup. The context suggests a test fixture for git-over-SSH, so it is most likely benign.
-
// 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 pythonhosted wheel URL with a sha256 fragment used as a test requirement.Reasoning
The blob is a sha256 fragment inside a test URL for a real PyPI wheel, passed to a requirement constructor. This is ordinary test fixture data, not obfuscation.
-
] sdist = wheels = -
] sdist = wheels = -
, ] "# -
, ] -
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 curl-to-sh install command for uv.
Reasoning
This is the documented official install one-liner for uv from astral.sh, shown to users. Piping a vendor install script to sh is a known convention, though it is a supply-chain trust decision the docs present openly.
-
likely benign Documentation showing a wget-to-sh install command for uv.
Reasoning
Same official uv installer pattern using wget, shown in documentation. Legitimate install instructions.
-
likely benign Landing page install command piping the astral.sh script to sh.
Reasoning
Same official uv installer one-liner in the project landing docs. Legitimate, widely documented install instruction.
-
()dismissed A documentation example comparing pip and uv pip list output with diff.Reasoning
The flagged command is diff inside a documentation example with process substitution. The variable-command finding is a false positive from markdown prose.
-
likely benign Reference docs showing the uv installer piped to sh with --help.
Reasoning
Official uv install script piped to sh with --help, shown in reference docs. Legitimate documentation of the installer.
-
if [; then elselikely benign A cargo wrapper script that execs cargo auditable via an optional REAL_CARGO path.Reasoning
A thin wrapper that execs cargo auditable, optionally using a REAL_CARGO override from the environment. Environment-controlled paths are a mild concern but this is a plausible build-tooling wrapper with no download or obfuscation.
-
CC=gcc else -
else -
# Make mold the default linker -
if [; then -
MANIFEST="artifacts/dist-manifest.json" assets=() while ;likely benign Release script invoking a sibling helper located via SCRIPT_DIR.Reasoning
SCRIPT_DIR is a standard script-directory variable set from a command substitution, and it runs a sibling helper script in the repo. Typical release tooling, not malicious.
-
if ; then filikely benign Test setup hook calling a sibling codesign script via SCRIPT_DIR.Reasoning
Same standard SCRIPT_DIR pattern invoking a codesign helper in the repo for test setup. Benign build/test tooling.
-
fi for; dolikely benign Wheel-test script running an installed binary path from a variable.Reasoning
The variable command comes from a loop over python and virtualenv paths set earlier in the script, which is truncated from the snippet. Context suggests a normal wheel smoke test.
-
for; dolikely benign Loop running --help on the installed uv, uvx and uv-build binaries in a venv.Reasoning
Loops over the fixed names uv, uvx and uv-build under a virtualenv bin directory to run --help. This is a smoke test of the built wheels with no external input.
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.
&&