Windows reproducible builder embeds sealed vendor paths in aware.exe

[pawellisowski]

The Windows internal reproducible builder reads vendored Rust dependencies from a verified sealed closure outside its private work directory, but remaps only the source directory, work directory and private CARGO_HOME. The actual vendor root survives in the executable. Two otherwise identical independent builds therefore fail their final byte comparison.

Reproduced on Windows x64 at integration commit 35e111b4ca99a390a51cfeb6e98c6878465354cd (tree 9c244050d4bd9d6629d7b6db25af825c80f7968f), Rust 1.95.0, MSVC 14.44.35207, through cli/build-windows-internal-repro.mjs. Both canonical manifests have build ID c4942bcd328c0667a515c5daebb182037668155521c2a448a240627fc9c1c767. The builders use separately materialized, byte-identical sealed closures and fresh output/target directories.

Artifact	Size	SHA-256
A aware.exe	16571904	479caa7572869ff525cddb0bbdf5dc3fa2367c7f4cb497cd82ae210a46345bda
B aware.exe	16571904	c553acb2bbacaef350e0df291c01751540f5ee2b492ee014f992ecabc0ea9ac0

The A binary contains its physical sealed-a/cargo-home/vendor/aes/src/soft/fixslice64.rs path; B contains sealed-b/.... The complete roots were observed in the bytes (local user paths omitted here). Dependency archives contain the corresponding paths too.

Reproduction:

1. Create two identical sealed cargo-home/npm closure inventories at different physical paths and identical canonical builder manifests, with local locators pointing to the respective copies.
2. Run the canonical Windows builder independently into two fresh output directories.
3. Compare the complete artifact inventories. Inspect each aware.exe for its physical vendor root: both retain it and their hashes differ.

A separate minimal native Rust probe using the current exported controlledEnvironment flags also reproduces the cause: put identical fn main() { println!("{}", file!()); } source under each vendor root outside workRoot, compile with identical crate name and /Brepro, and run it. Each prints its own physical path and the binaries differ. This is not a missing cache, compiler error, or caller argument misuse: cargoArguments deliberately consumes join(cargoClosure, 'vendor'), while controlledEnvironment receives and remaps the different, initially empty private cargoHome.

Expected: compiler remappings bind the actual verified Cargo vendor operand to a stable logical prefix, including Windows spelling/whitespace handling; final complete A/B inventories match. No binary patching or mismatch normalization should be used to pass the gate.

Related: #480 (private RVT reader integration). Correction is being hardened before code, including native regression and exact source/receipt binding. No signing, release promotion, or installer distribution has used these mismatching outputs.

[pawellisowski]

The first complete A/B after the compiler audit lifetime and debug-heap fixes still fails this issue's path-isolation acceptance. At integration commit 131dddcd1f401f487083ce0b1cd730ef06c87051 (tree 5223097178f01db97aa40a4a32eddbc6c0df8191), both sealed builds finish with complete audit v3 evidence (575 processes per side, zero active at completion). The strict scan finds physical copied-vendor roots in 53 compiled files, including aware.exe.

Both executable sizes are 16,518,144 bytes. SHA-256:

• A: 68271ee5e6364341d3cafb6103ba1b4890a040ac147386fbafd19578392ce662
• B: 626e01fdce2983870c6694323efaf7f4b645db980aef57111ab470eaba7ef841

Confirmed causes:

1. cargoArguments supplies --target x86_64-pc-windows-msvc. Cargo intentionally does not apply CARGO_ENCODED_RUSTFLAGS to HOST build dependencies/proc macros with explicit target selection. Actual host autocfg, cc, unicode_ident, and proc_macro2 invocations contain no path remaps, while target invocations contain all eight. Host .rlib/.rmeta retain source/vendor paths. This is a builder configuration defect, not a Cargo defect: https://doc.rust-lang.org/cargo/reference/config.html#buildrustflags
2. Native compilation uses only /Brepro; Rust remaps do not rewrite native object content. lzma.lib retains UTF-16 assertion paths from index.h, fastpos.h, and lzma_common.h reached through absolute include paths.
3. ring passes absolute pregenerated .o operands through cc to lib.exe, which preserves those names in the archive longnames table. This needs fixing before Rust bundles/links the archive, not by patching output bytes.

A small real pinned-MSVC probe reproduced narrow and wide source/header filename leakage. Passing relative source/include operands eliminates the filenames; /experimental:deterministic plus /pathmap:physical=logical also maps both forms and produces equal executable bytes under different roots, including a spaced Unicode root. /pathmap alone emits D9007 and is ignored. lib.exe /pathmap and /trimpath emit LNK4044 and are ignored. Passing relative object operands gives equal .lib bytes and stable archive member names. These are diagnostic probes, not acceptance of a corrected production builder.

The existing native regression used only an ordinary Rust dependency and a constant-printing C fixture; it did not exercise host units, header/assertion filenames, or native archive names. The correction will keep all scans, immutable closure checks, compiler audit/hash gates, and A/B equality assertions, and add these missing native cases before another full paired build. Packaging stopped at the failed scan; no signing or distribution used these outputs. Related: #489, #493.