[Windows security] Reject non-local frozen file authorities consistently without source echo #253

Problem

The frozen-fetch fail-closed path treats a file: URL with a remote authority differently on Windows than on Unix.

The existing regression uses:

file://remote-registry/secret-source

and requires a redacted, stable rejection containing not a local absolute path. On Unix, Url::to_file_path() rejects the authority. On Windows, the same URL can be interpreted as a UNC-style absolute path, so src/fetch.rs accepts the path conversion and fails later with different wording. The source is still not echoed, but the cross-platform security contract and test are inconsistent.

Independent discovery and final attribution

• Unmodified product base: zed-pkg/zed-cli@0ecd5b00cdd4c5df66824bd9ffdeb079b592a651
• Test: frozen_fetch_boundaries::non_local_file_registry_authority_fails_closed_without_source_echo
• Independent workflow: zed-pkg-test/security-adversarial-e2e, run 31272111594
• Evidence artifact: 9025997603
• Evidence digest: sha256:f2dd3a4c5adc14d204d0df6154f69ceb327bab125634bfb18f1ee277d8df6344
• Lock-migration candidate under certification: zed-pkg/zed-cli#246@7897b7f82df13729672c4b12dbb7934ed47a024a

The final workflow first ran the exact regression against unchanged main and required the exact Windows assertion failure. It then validated the unrelated six-file lock candidate with isolated Cargo configuration, exact boundary enforcement, locked all-target compilation, every other Windows test, the process-lock suite, and strict Clippy. The candidate passed. This is therefore a proven pre-existing Windows portability/security-message defect, not evidence against zed-lock mutual exclusion.

Related completed work

zed-pkg/zed-cli#238 fixed local Windows file:///C:/... registry conversion and rejects remote authorities in the registry-routing path. This issue covers the separate frozen artifact/source validation path in src/fetch.rs, which still delegates authority interpretation to platform-specific Url::to_file_path() behavior.

Required implementation

• Reject non-local file: authorities explicitly before converting the URL to a native path.
• Define the localhost policy explicitly and apply it consistently on Linux, macOS, and Windows.
• Preserve valid local Unix paths and Windows drive URLs such as file:///C:/path.
• Never echo the untrusted source URL, authority, path, query, fragment, or embedded secret in user-facing errors.
• Return a stable structured/error-classified message across operating systems.
• Avoid string-prefix parsing; use URL authority/path semantics.

Required tests

• Remote authority is rejected with the same redacted error on Linux, macOS, and Windows.
• The test proves a secret marker is absent from stdout and stderr.
• Valid Unix file:///tmp/... behavior remains supported.
• Valid Windows file:///C:/... behavior remains supported.
• localhost behavior is covered according to the documented policy.
• Percent encoding, query strings, fragments, IPv6-style authorities, and UNC-looking inputs fail closed without source echo where unsupported.
• Independent exact-head Windows Server 2025 certification is retained.

Interim certification rule

Until this issue lands, an independent Windows canary may exclude only the exact named regression after first proving the identical assertion failure on unchanged main. Any changed signature, unexpected pass, source echo, or additional failing test must fail closed.

Related: #237, #238, #246, Linear DEN-3097, Linear DEN-2076.