Skip to content

fix: prefer exact PATH during trusted executable resolution - #128

Open
GautamSharma99 wants to merge 1 commit into
openai:mainfrom
GautamSharma99:fix/posix-path-precedence
Open

fix: prefer exact PATH during trusted executable resolution#128
GautamSharma99 wants to merge 1 commit into
openai:mainfrom
GautamSharma99:fix/posix-path-precedence

Conversation

@GautamSharma99

Copy link
Copy Markdown
Contributor

Summary

Prefer the exact PATH environment variable when resolving trusted executables, while retaining the existing case-insensitive fallback for environments such as Windows that commonly expose the variable as Path or another casing.

Fixes #41.

Problem

resolveTrustedExecutable previously searched all environment entries case-insensitively and selected the first name whose uppercase form was PATH.

On POSIX, environment names are case-sensitive. path and PATH are separate variables, and process execution consults PATH. If a lowercase path entry appeared earlier in the supplied environment object, trusted executable resolution searched that value instead of the real POSIX PATH.

This made resolution depend on object insertion order. It could select a different Git or Python executable, or report that no trusted executable was available even though the actual PATH contained one. The selected value was also published as the sanitized child PATH.

Changes

  • Read environment["PATH"] first.
  • Use the existing case-insensitive environment scan only when the exact PATH value is unavailable.
  • Preserve the existing sanitization step that removes every casing variant before publishing one canonical child PATH.
  • Add a POSIX regression test with a lowercase path decoy inserted before the real PATH.
  • Verify that the trusted executable is selected from the exact PATH, the decoy is ignored, both original casing variants are removed, and the child receives only the sanitized canonical PATH.

Compatibility

Windows compatibility is preserved. Existing coverage continues to verify that mixed-case variables such as Path and pAtH are accepted when an exact PATH entry is not present.

An explicitly empty PATH also remains authoritative instead of unexpectedly falling back to a differently cased POSIX variable.

Security impact

This keeps the trusted-executable boundary aligned with POSIX environment semantics. A lowercase variable supplied by an SDK embedder or inherited from local tooling can no longer redirect Git or Python resolution when a valid exact PATH is present.

The change does not expand the existing trust boundary or alter executable canonicalization, protected-root rejection, executable permission checks, or child-environment sanitization.

Verification

  • pnpm run format
  • pnpm run types
  • pnpm run build
  • Focused trusted-executable, target normalization, and multiscan tests: 33 passed, 1 expected Windows-only skip, 0 failed
  • Full TypeScript suite: 471 passed, 6 expected platform/integration skips, 0 failed
  • git diff --check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

resolveTrustedExecutable can pick a lowercase path variable instead of PATH on POSIX

1 participant