pin-project-lite 0.2.17

Source: https://github.com/taiki-e/pin-project-lite
Tag scanned: v0.2.17
Compared with: v0.2.16 (7 signals introduced since)
Files: 66 scanned, 20 skipped (binary, oversized, or unrecognised)
Signals: 2 critical · 0 warn · 5 info
Scan time: 6.0 s
LLM review: Reviewed by claude-haiku-5-5 (Anthropic): 7 of 7 warn and critical signals; 5 demoted to info.
Disclude version: 4.0.0
Scanned (UTC): 2026-10-14 20:34

Signals

Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.

critical dynamic-execution tools/tidy.sh:985:48 new in this release

command name is a variable or substitution — executed command determined at runtime (ast pass, confidence 0.90)
```
if [[ -f tools/.tidy-check-license-headers ]]; then
  info "checking license headers (experimental)"
  failed_files=''
  for p in $(LC_ALL=C comm -12 <(eval "$(<tools/.tidy-check-license-headers)" | LC_ALL=C sort) <(ls_files | LC_ALL=C sort)); do
```
suspicious LLM, confidence 0.75 Evaluates a repo config file to produce a list of files for license header checks.
Reasoning
Process substitution evaluates contents of tools/.tidy-check-license-headers, a repository file that is part of the project's own tooling. This is a configuration-driven file list generator, which is unusual but not hidden malware; the risk depends on that file being trusted, which it is in-repo.
critical dynamic-execution tools/tidy.sh:987:34 new in this release

`eval` called on a dynamic (variable/substitution) expression (ast pass, confidence 0.90)
```
  failed_files=''
  for p in $(LC_ALL=C comm -12 <(eval "$(<tools/.tidy-check-license-headers)" | LC_ALL=C sort) <(ls_files | LC_ALL=C sort)); do
    case "${p##*/}" in
      *.stderr | *.expanded.rs) continue ;; # generated files
```
suspicious LLM, confidence 0.75 eval of the license-header config file inside the file-listing pipeline.
Reasoning
Same eval of tools/.tidy-check-license-headers as the preceding finding. It is in-repo tooling config, so the eval is a design choice with a code-execution implication rather than clear obfuscation; flagged as suspicious because it executes arbitrary content from a file.
info ~~warn~~ → info by review dynamic-execution tools/tidy.sh:31:8 new in this release

command name is a variable (`$@`) not set in this file — the caller or environment decides what runs (ast pass, confidence 0.70)
```
  for i in {1..10}; do
    if "$@"; then
      return 0
    else
```
likely benign LLM, confidence 0.90 Retry wrapper that executes its arguments as a command.
Reasoning
This is a retry helper that runs the command passed as arguments with a loop. Running caller-supplied commands is the purpose of a wrapper like this; no obfuscation or hidden payload is visible.
info ~~warn~~ → info by review dynamic-execution tools/tidy.sh:37:3 new in this release

command name is a variable (`$@`) not set in this file — the caller or environment decides what runs (ast pass, confidence 0.70)
```
  done
  "$@"
}
error() {
```
likely benign LLM, confidence 0.90 Same retry helper's final invocation of its arguments.
Reasoning
Final execution of "$@" in the same retry helper. It is a normal generic wrapper pattern in a repository tidy script, not a hidden execution path.
info ~~critical~~ → info by review dynamic-execution tools/tidy.sh:171:11 new in this release

`eval` called on a dynamic (variable/substitution) expression (ast pass, confidence 0.90)
```
        if type -P "g${tool}" >/dev/null; then
          eval "${tool}() { g${tool} \"\$@\"; }"
        fi
      done
```
likely benign LLM, confidence 0.80 eval defines wrapper functions mapping tool names to their g-prefixed GNU variants.
Reasoning
The eval builds shell function wrappers around locally discovered tools (g"${tool}" for gnu variants like gsed/gtar). The tool name comes from a fixed list in the script, so it is an ordinary, if clumsy, build-time shim rather than attacker-controlled input.
info ~~critical~~ → info by review dynamic-execution tools/tidy.sh:287:7 new in this release

`eval` called on a dynamic (variable/substitution) expression (ast pass, confidence 0.90)
```
    for pkg in $(jq -c '. as $metadata | .workspace_members[] as $id | $metadata.packages[] | select(.id == $id)' <<<"${metadata}"); do
      eval "$(jq -r '@sh "publish=\(.publish) manifest_path=\(.manifest_path)"' <<<"${pkg}")"
      if [[ "$(tomlq -c '.lints' "${manifest_path}")" == 'null' ]]; then
```
likely benign LLM, confidence 0.80 eval loads shell-quoted cargo package metadata fields into variables.
Reasoning
eval consumes output from jq @sh formatting of cargo metadata (publish and manifest_path). This is a common idiom for shell-quoting jq output; the input comes from the repository's own cargo metadata, not untrusted remote data, though eval of tool output is a fragile pattern.
info ~~warn~~ → info by review dynamic-execution tools/tidy.sh:425:9 new in this release

command name is a variable (`$workflow_path`) not set in this file — the caller or environment decides what runs (ast pass, confidence 0.70)
```
        alert="${line#*[\!}"
        alert="${alert%%]*}"
        alert=$(tr '[:lower:]' '[:upper:]' <<<"${alert%%]*}")
        alert_lower=$(tr '[:upper:]' '[:lower:]' <<<"${alert}")
```
likely benign LLM, confidence 0.70 Text processing of a GitHub workflow alert label using tr and parameter expansion.
Reasoning
The flagged line is string manipulation of an alert variable with tr and parameter expansion; no command is actually taken from $workflow_path here. The finding appears to be a misattribution from the surrounding code, so it looks like a parser false positive.

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.

cargo install disclude --version 4.0.0
git clone https://github.com/taiki-e/pin-project-lite pin-project-lite && cd pin-project-lite
git checkout v0.2.17
disclude scan --severity info --diff v0.2.16 .