disclude.iouv 0.13.3
- Source
- https://github.com/astral-sh/uv
- Tag scanned
0.13.3- Compared with
0.13.2(1 signals introduced since)- Files
- 1175 scanned, 652 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 1 warn · 117 info
- Scan time
- 73.3 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:13
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
ub const READ_ONLY_GITHUB_SSH_DEPLOY_KEY: &str = "LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0KYjNCbGJuTnphQzFyWlhrdGRqRUFBQUFBQkc1dmJtVUFBQUFFYm05dVpRQUFBQUFBQUFBQkFBQUFNd0FBQUF0emMyZ3RaVwpReU5UVXhPUUFBQUNBeTF1SnNZK1JXcWp1NkdIY3Z6a3AwS21yWDEwdmo3RUZqTkpNTkRqSGZPZ0FBQUpqWUpwVnAyQ2FWCmFRQUFBQXR6YzJndFpXUXlOVFV4T1FBQUlikely benign A base64-encoded SSH private key constant in a test crate.Reasoning
The constant is named READ_ONLY_GITHUB_SSH_DEPLOY_KEY and decodes to an OpenSSH private key, which is sensitive-looking. In a test crate it is most likely a fake or test key for git SSH tests. Its exact nature cannot be confirmed from the snippet, so the verdict is not certain.
-
info
warn→ info by reviewdynamic-executiondocs/getting-started/installation.md:28:5new in this releaselikely benign Docs showing a versioned uv install script piped to sh.Reasoning
Documentation example pinning the installer to a specific version path on the official astral.sh domain, piped to sh. Legitimate install documentation.
-
likely benign Smoke-test step that runs the built package's CLI entry point via a variable name.
Reasoning
The variable command name is ${MODULE_NAME} in a release workflow that installs the just-built wheel or sdist and smoke-tests its CLI with --help. The variable is the project's own entry-point name, set elsewhere in the repo, so this is a normal post-build check rather than dynamic dispatch of attacker-controlled code.
-
likely benign Post-build smoke test of the uv-build CLI and module via variable names.
Reasoning
Same pattern as the other build step: after installing the freshly built uv-build package, it runs ${MODULE_NAME}-build and python -m ${MODULE_NAME}_build with --help. The name comes from the project's own build configuration, so this is a routine verification step.
-
likely benign Install-and-smoke-test step invoking the project's CLI via a variable name.
Reasoning
This is the same smoke-test pattern at a different job: the package installed from the local dist/ directory is exercised with its own entry point name. The flag is the scanner's generic rule about variable command names, and nothing here fetches or runs untrusted content.
-
likely benign Smoke-test of the locally built uv-build package via variable entry-point names.
Reasoning
Installs the locally built uv-build wheel from crates/uv-build/dist and runs its CLI and module with --help. This is a standard verification of the built artifact.
-
# Namespace runners do not include winget.likely benign Assignment of the pinned NASM version used to construct the download URL.Reasoning
The variable is a pinned NASM version string used to build an installer filename and download URL. It is a plain string assignment in the Windows setup, not a command being executed. The flag is a false positive from the variable-command rule.
-
likely benign Hardcoded SHA-256 for verifying the downloaded NASM installer.
Reasoning
This assigns a hardcoded SHA-256 checksum for the NASM installer. The checksum is a string constant, and its presence supports integrity verification of the download. Nothing is executed through this variable.
-
likely benign Downloads the pinned NASM Windows installer from the official nasm.us release site.
Reasoning
Builds a path to the downloaded installer in RUNNER_TEMP and fetches it from the official nasm.us release URL using a pinned version. The verification step after the download is not in the snippet, but the source is a legitimate vendor site. The flag concerns the rule's variable-command heuristic, not a real execution risk.
-
if ()likely benign Silent install of NASM with exit-code check.Reasoning
Runs the downloaded NASM installer silently with /S and checks its exit code. This is an ordinary Windows toolchain install step. The scanner flags the variable name $installation, which is a false positive for the variable-command rule.
-
if ()likely benign Error check on the NASM installer exit code.Reasoning
This is the exit-code check on the NASM installer process, throwing if the install fails. It is defensive error handling with no execution risk; the flag is a rule false positive.
-
if () |likely benign Adds the NASM install directory to the runner PATH.Reasoning
Appends the NASM install directory to GITHUB_PATH so later steps can find nasm. This is a standard, expected way to extend PATH in GitHub Actions. The flag is a false positive from the variable-command rule.
-
info
critical→ info by reviewdynamic-execution.github/workflows/build-release-binaries.yml:384:13IMPORTS_FILE="/-coff-imports.txt" if ; thenlikely benign A release CI step runs an LLVM readobj tool, found via a variable, to inspect Windows binary imports.Reasoning
The command name is a variable holding an llvm-readobj path, and that path is set earlier in the same CI job. The step runs llvm-readobj on the release binary's COFF imports and greps for CRT DLL names, which is a plausible Windows-runtime compatibility check. Nothing in the snippet is encoded, fetched from a remote source, or piped to a shell. The critical severity overstates a common CI pattern, though the variable's origin is outside the snippet.
-
likely benign A CI smoke test runs the freshly installed package's CLI via a MODULE_NAME variable.
Reasoning
This is a release-workflow smoke test. ${MODULE_NAME} is the package's own CLI or module name, set by the workflow environment, and it runs --help after installing the locally built wheel. The variable indirection is ordinary CI templating and the step does nothing beyond invoking the package it just built.
-
likely benign A CI smoke test invokes the build-backend CLI through a MODULE_NAME variable.
Reasoning
This is the same release smoke-test pattern for the build backend package. ${MODULE_NAME}-build --help runs the package's own just-installed CLI, with no external fetch or obfuscation.
-
likely benign A release smoke test runs the installed package's CLI via MODULE_NAME.
Reasoning
This matches the other smoke-test steps in the release workflow: it installs the locally built wheel and runs its help command. The variable-named command is the package's own entry point.
-
likely benign A release smoke test runs the build-backend CLI via MODULE_NAME.
Reasoning
This is the build-backend smoke test again, installing a local wheel and calling its own CLI with --help. Nothing in it is malicious or obfuscated.
-
likely benign A release smoke test runs the installed package's CLI via MODULE_NAME.
Reasoning
This is another instance of the release-workflow smoke test. It installs the artifact built in the same job and runs the package's own help command.
-
likely benign A release smoke test runs the build-backend CLI via MODULE_NAME.
Reasoning
This is the build-backend smoke test from the release workflow, invoking the package's own CLI after a local install. The pattern is standard and not an attack.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here. # python -m ${MODULE_NAME} --helplikely benign A platform-specific release smoke test runs the installed package's CLI via MODULE_NAME.Reasoning
This is a release smoke test on a platform-specific job. It installs a wheel from /dist and runs the package's own CLI. The commented-out lines are an upstream TODO about test discovery, not concealment.
-
# 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 A platform-specific release smoke test runs the build-backend CLI via MODULE_NAME.Reasoning
This is the build-backend smoke test on a platform-specific job. It installs a wheel from /dist and runs the package's own CLI, with the same 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} --helplikely benign A platform-specific release smoke test runs the installed package's CLI via MODULE_NAME.Reasoning
This is another platform-specific release smoke test. It installs the locally built wheel and runs its help command, with no external or obfuscated 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 CI smoke test that runs the freshly built binary whose name is taken from a workflow variable.Reasoning
The command name $MODULE_NAME comes from the CI workflow's own environment, where the project sets it to its built binary name. The step installs a package it just built from /dist and smoke-tests its --help output. This is standard release-testing practice, not an injected command.
-
# 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 smoke test of the built CLI using a workflow-defined module name.Reasoning
Same pattern as the other release-workflow findings: $MODULE_NAME is a project-defined variable, and the step runs --help on a package installed from the local /dist artifacts. Nothing here fetches or runs untrusted content.
-
# 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 Installs the built build-tool wheel and runs its help command as a smoke test.Reasoning
The step installs the locally built wheel from /dist and runs its --help command. The variable-named command is the project's own binary, so the flag reflects a template or matrix variable rather than 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 Virtualenv smoke test that runs the installed release binary by its workflow-defined name.Reasoning
The step installs the locally built package into a virtualenv and runs the command from .venv/bin. The variable name refers to the project's own binary, and the test runs only on artifacts the workflow itself produced.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here.likely benign Virtualenv smoke test of the built build-tool binary using a workflow variable for its name.Reasoning
This is the build-tool variant of the same release-test step. It installs the local /dist artifact into .venv and runs its help output. The variable-based command name is expected in a templated release workflow.
-
# 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 Installs the locally built package and smoke-tests it through a workflow variable.Reasoning
This step installs the locally built package and invokes it by a variable-derived name for a --help check. The source is the project's own CI variable and local build artifacts, so there is no sign of injection.
-
# 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 help check of the built command, with the name supplied by the workflow.Reasoning
The pattern matches the other release-test steps: a local /dist install followed by --help on the project's own command. The variable is a standard templating mechanism in CI.
-
# TODO(konsti): Enable this test on all platforms, currently `find_uv_bin` is failing to discover uv here.likely benign Virtualenv test of the built binary, with the command name taken from a workflow variable.Reasoning
The step installs the local build artifact into .venv and runs the variable-named tool with --help. It exercises the release output in CI and does not download or execute anything external.
-
# 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 package's help command in CI.Reasoning
The step installs the locally built package and runs its help command. The variable name is the project's own, and the surrounding commands only test artifacts produced earlier in the same workflow.
-
|likely benign CI step that installs the hawk tool by piping its release installer script from GitHub to sh.Reasoning
The workflow downloads an installer script from the official astral-sh GitHub releases, using a pinned version variable and HTTPS with TLS 1.2 enforced, then pipes it to sh. This is the standard cargo-dist installer pattern. Piping remote code to a shell is a real supply-chain risk, but the source is a trusted project release host, so the finding is likely a legitimate installation step.
-
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 runs a command held in $cmd, choosing between a local uv binary and the plain command.Reasoning
The snippet shows a loop that checks whether $cmd starts with uv and then runs it either as a local ./ binary or as a plain command. This is a test runner iterating over commands defined by the workflow matrix or loop setup, which is a normal CI pattern. The variable is not shown being set, but the surrounding logic is consistent with test orchestration rather than injection.
-
else filikely benign The else branch of the same CI test loop runs $cmd as a plain command.Reasoning
This is the else branch of the same test loop, running $cmd as a command. The value comes from the workflow's own test matrix or loop, and nothing in the snippet suggests attacker-controlled input or encoded content.
-
# Call Python Install Manager's py.exe by full path to avoid legacy py.exe &dismissed A PowerShell step invokes py.exe by its full WindowsApps path to install Python 3.14.Reasoning
This is PowerShell, not bash. `$env:LOCALAPPDATA` is a PowerShell environment variable reference, and the line calls the Python Install Manager's py.exe by full path with a comment explaining why. The scanner misread `$env:` as a shell variable used as a command name.
-
if ! ; then -
if ! ; then -
likely benign A CI step sources the activate script of a venv it just created.
Reasoning
The script sources the venv activate script at $PYODIDE_VENV/bin/activate, which the same step just created with `uv venv`. Sourcing a venv activation script is standard practice, and the path is a workflow-local directory, not remote or attacker-controlled.
-
&dismissed A PowerShell step activates a Windows venv via a relative backslash path.Reasoning
`.\venv-native\Scripts\Activate.ps1` is an ordinary Windows relative path with backslash separators. The scanner counted the path separators as escape sequences. Nothing is hidden.
-
dismissed A PowerShell step exports pyodide configuration values to GITHUB_ENV.
Reasoning
This is PowerShell assignment and pipeline code using `$env:PYODIDE_PYTHON`, `pyodide config get`, and `$env:GITHUB_ENV`. This is the standard way to export values to later steps in GitHub Actions on Windows. The scanner misread `$env:` as a shell variable used as a command.
-
dismissed A PowerShell step exports the pyodide package index to GITHUB_ENV.
Reasoning
This is the same PowerShell pattern as the previous line: exporting config values by writing to GITHUB_ENV. It is an ordinary CI construct, and the flagged `$env:` is a PowerShell variable, not a command name.
-
&dismissed A PowerShell step runs a local uv.exe and activates a Windows venv.Reasoning
`.\uv.exe` and `.\venv-pyodide\Scripts\Activate.ps1` are ordinary Windows relative paths. Backslashes in Windows paths were counted as escape sequences. Nothing is hidden or obfuscated.
-
# Add pyenv-win to PATH for this sessiondismissed A PowerShell step sets PYENV and prepends pyenv-win directories to PATH.Reasoning
This PowerShell code sets PYENV from `$env:USERPROFILE` and prepends it to PATH. This is a normal way to set up pyenv-win on a Windows runner. The `$env:` prefix is a PowerShell variable reference, not an executed command.
-
# Add to GITHUB_PATH so WSL can find the shimsdismissed A PowerShell step prepends pyenv-win bin and shims directories to PATH.Reasoning
This is the PATH assignment line from the same pyenv-win setup. It assigns a PowerShell environment variable from other environment variables and a known install directory. Nothing is executed dynamically.
-
& &dismissed A PowerShell step installs and sets Python 3.11.9 with pyenv-win.Reasoning
The step calls pyenv.bat from its known install location to install and set the global Python 3.11.9. This is a normal CI setup step, and `$env:PYENV` is a PowerShell variable reference, not a dynamically chosen command.
-
& &dismissed A PowerShell step sets the global pyenv-win Python version to 3.11.9.Reasoning
This is the global-version line of the same pyenv-win setup, calling pyenv.bat from its install directory. It is benign CI configuration.
-
&likely benign Runs the pyenv-win binary from a path built from an environment variable during a Windows CI test step.Reasoning
The line invokes pyenv-win via the call operator on a path built from the $env:PYENV variable, which the CI workflow sets to the installed pyenv location. The flagged 'variable command name' is a normal PowerShell invocation of a known local tool, not injected code.
-
likely benign Evaluates uv's self-generated bash completion script in a CI smoke test.
Reasoning
eval over output of the project's own uv binary generating its bash completion script is a standard, self-contained pattern in uv's own CI smoke tests. No external source is fetched.
-
likely benign Evaluates uvx's self-generated shell completion output in a CI smoke test.
Reasoning
Same as the adjacent line: eval of the locally built uvx completion output in a CI smoke test, with no external input.
-
likely benign Evaluates the project's generated shell completion script in a CI job.
Reasoning
Repeated identical eval of the project's own generated completion script in another smoke-test job; standard CI behavior.
-
likely benign Evaluates the project's generated uvx completion script in a CI job.
Reasoning
Same self-generated completion eval as the other jobs in this workflow; no untrusted input is involved.
-
likely benign Evaluates the project's generated shell completion script in a CI job.
Reasoning
Repeated self-generated completion eval in a further smoke-test job; benign CI pattern.
-
likely benign Evaluates the project's generated uvx completion script in a CI job.
Reasoning
Same self-generated uvx completion eval; no external or attacker-controlled input.
-
dismissed Sets PATH in a PowerShell CI step; the flag is a parser misreading of an assignment.
Reasoning
The flagged 'command' is the PowerShell assignment target $env:PATH, which the parser misread as a command. The real command is a local Python script invocation. This is a parser false positive.
-
dismissed Passes a Python version variable as an argument to a local check script in CI.
Reasoning
The flagged $env:TEST_PYTHON_VERSION is an argument value to a local Python check script, not a command name. The finding misreads a variable argument as code execution.
-
# Install pyenv | # Set up environment variables for current steplikely benign Installs pyenv in a CI step by piping the official pyenv.run installer into bash.Reasoning
curl piped to bash is a risky supply-chain pattern, but it is the documented pyenv installer from its official domain in a CI setup step. It is a known installer, not obfuscated payload delivery, though a pinned or verified install would be safer.
-
# Install Python 3.9likely benign Initializes pyenv in the shell via eval of its own init output in CI.Reasoning
eval "$(pyenv init -)" is the standard documented way to initialize pyenv in a shell. It evaluates the locally installed tool's output and is not attacker-controlled.
-
|dismissed Assigns cargo bloat output to a PowerShell variable; flag is a misparse of an assignment.Reasoning
The flagged command is the PowerShell variable assignment target $output, a parser false positive. The line assigns the output of a cargo bloat run and does not execute a variable as a command.
-
| |dismissed Filters command output into a PowerShell variable; flag is a misparse of an assignment.Reasoning
The flagged name is the PowerShell assignment target $filteredOutput, a parser false positive. The line filters text with Select-String and does not execute anything dynamically.
-
| | if ()dismissed A PowerShell step in a CI workflow that greps test output for symbol patterns.Reasoning
The flagged token is a PowerShell variable in an `if ($containsPatterns)` condition, not a command being invoked. The pass misparsed the embedded script, and the step only greps test output for panic and fmt patterns.
-
if ()dismissed The else/if branch of the same CI step, which exits non-zero on unwanted output.Reasoning
The same variable-in-condition misparse. The `Exit 1` branch is a plain failure exit when the output contains unexpected patterns, which is ordinary CI logic.
-
# On macOS and Linux. |likely benign Documentation showing the curl-to-sh installer command for uv.Reasoning
This is the documented uv install one-liner from astral.sh. Piping an install script to sh is a known pattern that carries supply-chain risk, but it is the project's own official instruction in its README.
-
dismissed IPA pronunciation characters in the README prose.
Reasoning
The IPA transcription /juː/ uses the Unicode long-i and ɪ-style symbols. Mixing Latin with IPA characters in prose is expected and not an identifier or obfuscation.
-
dismissed IPA pronunciation characters in the README prose.
Reasoning
Same as the previous finding: the IPA symbol in a pronunciation guide in Markdown 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 sha256 hash in a test HTML link to a Jinja2 wheel.Reasoning
The match is a sha256 hex digest in a URL fragment inside an HTML test fixture. It is a hex string, not base64, and it is a normal package-index hash.
-
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 Test string of byte escapes used to exercise path decoding.Reasoning
The escapes are byte literals in a Rust test case that checks how Python's fsdecode handles non-UTF-8 paths. They are test data for path handling, 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 Test fixture of high-byte escape sequences for path decoding.Reasoning
A run of byte escapes in a path-decoding test fixture, covering the full byte range. This is expected for testing non-UTF-8 handling.
-
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 Test fixture of byte escapes for path decoding.Reasoning
Byte-range test data in the same path-decoding test table. The escapes encode the high-byte range expected by the 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")"#, ), ]likely benign Test fixture of byte escapes for path decoding.Reasoning
The final byte-range segment of the same test table. The data is test input 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 test array of base64-encoded values used in uv tests.Reasoning
The array holds short base64 strings that decode to ordinary test content such as 'pat'. This is test fixture data in a Rust test helper.
-
"cGF0Cg==", "MTFBQlVDUjZBMDJTOFYwMTM4YmQ0bV9uTXpueWhxZDBrcllROTQ5SERTeTI0dENKZ2lmdzIybDFSR2s1SE04QW8xTUVYQ1I0Q1YxYUdPRGpvZQo=", ];likely benign A test array of base64-encoded values.Reasoning
Base64 test values in a test array of encoded strings. They look like generated test inputs, not a dropper or hidden logic.
-
// 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 fragment.Reasoning
A base64-like string inside a Rust test fixture is a URL with a sha256 hash fragment for a real anyio wheel on pythonhosted.org. Raw-pass entropy/encoding heuristics misfire on URLs and hex-ish hashes; no decoding or execution occurs.
-
] 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 Docs showing the official curl-to-sh uv install command.
Reasoning
Documentation showing the official uv installer one-liner piped to sh. This is a common, legitimate install method from the project's own domain; the flag is the pattern itself, not evidence of malice, though curl-pipe-sh carries inherent supply-chain risk.
-
likely benign Docs showing the official wget-to-sh uv install command.
Reasoning
Same official uv installer command, using wget instead of curl, in documentation for the project's own install script.
-
likely benign Index docs showing the official uv curl-to-sh install command.
Reasoning
Project landing page showing the standard official curl-to-sh install command. Common legitimate pattern in docs.
-
()dismissed Docs example comparing pip and uv pip list output with diff.Reasoning
Shell example in docs using process substitution with diff over pip list and uv pip list output. The $diff 'variable' is a false positive from the markdown parser treating the command name as a variable; no malicious behavior.
-
likely benign Docs showing the official install script with --help via sh.
Reasoning
Documentation example of the official install script piped to sh with a --help argument. Legitimate documentation of the installer.
-
if [; then elselikely benign Cargo wrapper script that execs cargo auditable via an optional REAL_CARGO path.Reasoning
Wrapper script that execs cargo auditable, optionally using a REAL_CARGO override from the environment. This is a build-tooling wrapper; exec of a variable path is expected for such a shim, though the env-controlled path is a minor concern in a repo script.
-
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 in its own directory.Reasoning
Release script runs a sibling helper from SCRIPT_DIR, which is derived from the script's own location; the flagged pattern is ordinary repo-local script invocation rather than attacker-controlled execution.
-
if ; then filikely benign Test hook invoking a local codesign helper script.Reasoning
Test setup hook calls codesign-macos.sh from SCRIPT_DIR with the identity from an env var. Standard repo-local helper invocation in a test script.
-
fi for; dolikely benign Wheel-testing script installing built wheels with a locally defined Python.Reasoning
Release-testing script runs the python array to pip install wheels; the 'variable command' flag arises from the array expansion of a locally defined interpreter. Normal CI test tooling.
-
for; dolikely benign Smoke test running installed uv binaries from a local venv.Reasoning
Loop executes uv, uvx, and uv-build from a virtual environment path created earlier in the same script to check --help. Expected behavior for smoke-testing release binaries.
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.
&&