[mnriem]

Description

Fix Azure CLI executable resolution for Azure DevOps authentication. Resolve only absolute executable candidates from absolute PATH entries outside the current working directory, including checks for symlink aliases. Retain Windows PATHEXT support for the Azure CLI shim and return no token when no eligible executable is found instead of falling back to bare az.

Update authentication documentation and executable-resolution coverage, and give the catalog authentication tests explicit Azure CLI executable fixtures.

Testing

• Tested locally with uv run specify --help
• Ran existing tests with uv sync && uv run pytest
• Tested with a sample project (if applicable)

Validation used this worktree's own virtual environment, as recommended in CONTRIBUTING.md, rather than the bare uv run pytest invocation above:

• uv run specify --help — passed.
• LC_ALL=en_US.UTF-8 .venv/bin/python -m pytest tests/specify_cli/authentication tests/specify_cli/workflows/test_mcp.py -q -o addopts='' --disable-warnings — passed: 395 tests.
• LC_ALL=en_US.UTF-8 .venv/bin/python -m pytest tests -q -n 4 -o addopts='' --disable-warnings — passed: 13,673 passed, 130 skipped, 63 warnings.

Sample-project slash-command testing is not applicable to this authentication-only change. Validation ran on macOS; native Windows execution was not performed.

AI Disclosure

• I did not use AI assistance for this contribution
• I did use AI assistance (fill in the disclosure below)

AI disclosure: GitHub Copilot using GPT-6.1 Sol (model ID: gpt-6.1-sol) in autonomous agent mode under user direction, with no explicit reasoning-effort override, generated the implementation, tests, documentation, commit message, and PR description and ran the automated validation. No human line-by-line review is claimed.

[Copilot]

🟡 Changes recommended

Azure CLI resolution can still launch project-local executables on case-insensitive macOS volumes and fail to discover Windows shims on supported Python 3.11.

4 open issues

• Use samefile to detect project-local PATH entries · New
• Probe PATHEXT candidates for Windows Azure CLI lookup · New
• Compare Windows executable paths case-insensitively · New
• Add regression coverage for executable symlink resolution · New

What changed in this PR

This PR hardens Azure DevOps authentication in Specify CLI by restricting how Azure CLI is located before token acquisition.

Changes:

• Filters executable discovery to eligible absolute PATH entries and removes the bare-az fallback.
• Adds unsafe-path regression cases and explicit executable fixtures for authentication and catalog tests.
• Documents the executable-resolution requirements.

Review verification used isolated checks and source inspection; the full test suite and before/after regression comparison were not rerun.

File	Description
tests/​specify_cli/​workflows/​test_mcp.py	Adds an Azure CLI fixture and checks the executable used for catalog authentication.
tests/​specify_cli/​authentication/​test_authentication.py	Adds executable fixtures and rejection cases for unsafe search paths.
src/​specify_cli/​authentication/​azure_devops.py	Restricts executable lookup and returns no token when no eligible candidate exists.
docs/​reference/​authentication.md	Explains eligible Azure CLI locations and the no-fallback behavior.

_{Review effort: Max (auto)}

[mnriem]

The executable-target check follows symlink chains with realpath() and compares the resolved parent to the working directory using samefile(). The existing cases cover direct and case-aliased targets in cwd, rejection with and without a later valid installation, and acceptance of external targets. Commit 4d64989c2330683719ba4cc39ab4c09cc3355825 adds chained executable links back into cwd to the same cases; both are rejected without launching the cwd executable. I have not reproduced a symlink bypass in these paths. Absolute PATH entries for child directories remain intentionally eligible, as documented. This thread is left unresolved for your review. Posted on behalf of @mnriem by GitHub Copilot (model: GPT-6.1 Sol, autonomous agent mode, no explicit reasoning-effort override); the implementation, tests, and this reply were AI-generated.

[mnriem]

Addressed all four findings in 0811744: executable discovery now uses filesystem identity for both directory checks, explicitly probes Windows PATHEXT candidates for Python 3.11 compatibility, normalizes Windows path assertions, and covers executable symlinks into the working directory, fallback installations, external targets, and inspection failures. The full macOS suite passed with 13,696 passed and 130 skipped; native Windows validation is pending CI, and Python 3.11 Windows lookup behavior is covered by simulated regression tests. Threads remain unresolved. Posted on behalf of @mnriem by GitHub Copilot (model: GPT-6.1 Sol, autonomous agent mode, no explicit reasoning-effort override); the implementation, tests, documentation, and this comment were AI-generated.

[Copilot]

🔵 Needs a closer look

The authentication documentation overstates PATH protection by claiming project-local executables are excluded even though absolute entries for project subdirectories remain eligible.

2 open issues

• Compare Windows executable paths case-insensitively
• Add regression coverage for executable symlink resolution

1 previously missed issue

In code that hasn't changed since last review

Narrow PATH protection scope to current-directory aliases

docs/​reference/​authentication.md:232

An absolute PATH entry such as <cwd>/.venv/bin is still accepted, so the claim that project-local executables are excluded overstates the authentication protection. Describe the narrower rule—excluding the current directory itself and its aliases—and state that absolute entries for its subdirectories remain eligible.

2 resolved since last review

• Use samefile to detect project-local PATH entries
• Probe PATHEXT candidates for Windows Azure CLI lookup

_{Review effort: Max (auto)}

[mnriem]

Clarified the authentication documentation in dcafe14: discovery excludes the current directory itself and its symlink/case aliases, while absolute PATH entries for subdirectories such as /.venv/bin remain eligible. This is a documentation-only correction, with no executable behavior changes. The two carried-over findings were addressed in 0811744: authentication and catalog assertions compare Windows paths using normcase, and executable-symlink tests cover rejecting current-directory targets with and without a later valid installation and accepting external targets. Threads remain unresolved. Posted on behalf of @mnriem by GitHub Copilot (model: GPT-6.1 Sol, autonomous agent mode, no explicit reasoning-effort override); the documentation change and this comment were AI-generated.

[Copilot]

🔵 Needs a closer look

Human review is needed to assess the regression risk from missing positive test coverage for supported absolute PATH entries beneath cwd.

1 open issue

• Add regression coverage for executable symlink resolution

1 resolved since last review

• Compare Windows executable paths case-insensitively

_{Review effort: Max (auto)}

[mnriem]

Added positive coverage in 5bd403a: test_resolve_token_azure_cli_absolute_path_beneath_cwd verifies successful token acquisition through an absolute /.venv/bin PATH entry using real filesystem discovery, with only subprocess execution mocked. The shared executable fixture also exercises .exe and .cmd installations on Windows. The existing test_resolve_token_azure_cli_executable_symlinks cases cover rejecting executable symlinks into the working directory both with and without a later valid installation, and accepting symlinks to external installations. All 371 authentication tests passed locally. This change adds tests only; runtime behavior and documentation are unchanged, and review threads remain unresolved. Posted on behalf of @mnriem by GitHub Copilot (model: GPT-6.1 Sol, autonomous agent mode, no explicit reasoning-effort override); the test and this comment were AI-generated.

[Copilot]

🔵 Needs a closer look

Human assessment is needed to evaluate a potential symlink-based bypass of current-directory execution protections and excessive Windows executable-lookup overhead.

1 open issue

• Add regression coverage for executable symlink resolution

_{Review effort: Max (auto)}

[mnriem]

Addressed the Windows lookup overhead in 4d64989 by checking each explicit PATHEXT candidate directly rather than invoking another extension-expanding shutil.which lookup. Regression coverage verifies candidate probe counts for found, missing, and inaccessible executables; the current-directory target check is preserved, and chained executable symlinks into cwd are now covered with and without a later valid installation. No symlink bypass was reproduced in these cases. The full macOS suite passed with 13,708 passed and 130 skipped; native Windows validation is pending CI. Replied in the existing symlink thread without resolving it. Posted on behalf of @mnriem by GitHub Copilot (model: GPT-6.1 Sol, autonomous agent mode, no explicit reasoning-effort override); the implementation, tests, and this comment were AI-generated.

[Copilot]

🔵 Needs a closer look

Human judgment is needed to assess the minor mismatch between the authentication test’s description and the resolved-CLI launch-failure path it now covers.

1 open issue

• Add regression coverage for executable symlink resolution

_{Review effort: Max (auto)}