[GH-ISSUE #2930] [Bug] Windows browser verifiers lack an explicit ordinary-user launch prerequisite #1032

New issue

Closed

opened 2026-10-15 18:30:29 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:30:29 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2930

Real Windows E2E exposes an Edge fixture launch handoff: the launch root exits0 before CDP becomes ready. The verifier correctly rejects an exited root, but its launch parameters allow Edge to replace that root. Production Playwright-based CLI workflows passed; this issue concerns the two verifier fixture launch producers.

Pinned main: d4f0c5e664. Relevant launch/startup sources remain unchanged on refreshed main7a6defab1. Windows11 x64, Node24.18.0, Edge154.0.4258.48, headless with sandbox enabled, fresh private test profile and self-owned loopback site; no user browser/profile was controlled.

Observed failures: runtime verifier BrowserStartupError(exited) at1484ms (root exit0, empty stderr), and four nested source-map cases at the same startup boundary. Their map operations were not reached. Ordinary browser network/DOM/scripts/modules and ordinary source-map capture passed.

A fresh discriminating pair using the native-owned launcher:

Original fixture parameters: retained root24772 exits0 at1431ms; CDP ready3483ms identifies browser105156. Aggregate Job activity remains true, but does not prove that this different browser belongs to the specific retained Job.
Adding only --disable-features=AutoDeElevate: retained root108944 remains alive when CDP is ready1933ms, and SystemInfo.getProcessInfo identifies browser108944. Installed pinned Playwright already disables this feature.
In both controls, owned cleanup succeeds, the original browser-GUID endpoint is unavailable on three post-cleanup observations, profile removal succeeds and enclosing Job activeProcesses0. Endpoint disappearance supports cleanup, but is weaker than specific Job membership proof.

An earlier --edge-skip-compat-layer-relaunch-only control still handed off and is not an established fix. Earlier descriptions that aggregate Job activity proves custody were too strong; these newer observations explicitly separate readiness, root identity and custody.

Authority/prerequisite refinement from the subsequent ordinary-user controls:

Direct native observation of the WSL-launched Windows caller: elevated=true, administrator=true, integrityLevel12288 (high). The recovered ordinary fixture caller: elevated=false, administrator=false, integrityLevel8192 (medium), unchanged before/after each test.
With ordinary caller and original arguments, CDP is ready1775ms, browser PID106648 matches the still-live retained root. Owned cleanup succeeds and the exact endpoint is unavailable three times; profile removed/outerJob0.
Ordinary caller plus feature flag also passes (ready2291ms), so the flag is not needed by the current evidence.
Native CreateProcessW uses the caller security context; TokenOwner normalization does not lower elevation/integrity. Disabling AutoDeElevate under an elevated caller therefore does not establish ordinary browser authority. Actual browser token integrity remains unmeasured.

The narrow correction is a shared explicit ordinary-user Windows fixture preflight, before site/profile allocation, with actionable refusal for elevated/non-ordinary callers. Follow the existing packaged-Ghidra verifier precedent and existing native caller-token observation; do not silently borrow desktop tokens or change caller authority inside the verifier. Run the audit through the separately established ordinary route. Preserve original browser arguments/sandbox, existing fail-closed early root-exit rejection and startup deadline. No startup-wait relaxation, feature flag or production CLI launch-policy change is justified. This issue concerns missing explicit fixture prerequisites/diagnostics under the elevated audit caller, not a reproduced failure with a normal ordinary caller.

Regression: real Edge must report the still-live retained root as browser around the readiness query; cleanup must make that exact endpoint unavailable. Preserve spawn failure, zero/nonzero exit, signal, timeout and stale/late-port rejection. Rerun actual runtime, all nested source-map cases and composite CLI/MCP verification serially.

Receipts for this pair: original6.50s/110.6MiB peak native Job commit/2.13s sampled family CPU/114.2MiB sampled family working set; feature-disabled4.99s/112.2MiB/2.36s/117.7MiB. BelowNormal, two logical CPUs,2GiB outer Job bound; PowerShell observer unmeasured. One pair does not establish general speed improvement. Full local evidence: /tmp/rea-windows-e2e-20261013/results/edge-custody-*.stdout and receipts. No profiles, binaries or ambient environment are published.

Ordinary controls: original4.926s/110.8MiB peakJob/2.203s sampled CPU/115.0MiB sampled WS; flagged7.268s/130.6MiB/2.109s/114.6MiB; bothJob0. Actual ordinary unmodified runtime and all four nested-map workflows now pass: runtime70.576s/1101.7MiB peakJob/50.328s sampled CPU/1039.7MiB sampled WS; source-maps201.713s/792.4MiB/187.172s/948.9MiB. BothJob0 and native caller token unchanged. Source-map outerbudget600s explicitly accommodated the multi-case composite, but it completed below the prior300s ceiling. The original high-caller failures did not establish map defects.

Originally created by @N0zoM1z0 on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2930 Real Windows E2E exposes an Edge fixture launch handoff: the launch root exits0 before CDP becomes ready. The verifier correctly rejects an exited root, but its launch parameters allow Edge to replace that root. Production Playwright-based CLI workflows passed; this issue concerns the two verifier fixture launch producers. Pinned main: d4f0c5e664e26fe7ed1566dcc4b85ea9b57d52da. Relevant launch/startup sources remain unchanged on refreshed main7a6defab1. Windows11 x64, Node24.18.0, Edge154.0.4258.48, headless with sandbox enabled, fresh private test profile and self-owned loopback site; no user browser/profile was controlled. Observed failures: runtime verifier `BrowserStartupError(exited)` at1484ms (root exit0, empty stderr), and four nested source-map cases at the same startup boundary. Their map operations were not reached. Ordinary browser network/DOM/scripts/modules and ordinary source-map capture passed. A fresh discriminating pair using the native-owned launcher: - Original fixture parameters: retained root24772 exits0 at1431ms; CDP ready3483ms identifies browser105156. Aggregate Job activity remains true, but does **not** prove that this different browser belongs to the specific retained Job. - Adding only `--disable-features=AutoDeElevate`: retained root108944 remains alive when CDP is ready1933ms, and `SystemInfo.getProcessInfo` identifies browser108944. Installed pinned Playwright already disables this feature. - In both controls, owned cleanup succeeds, the original browser-GUID endpoint is unavailable on three post-cleanup observations, profile removal succeeds and enclosing Job activeProcesses0. Endpoint disappearance supports cleanup, but is weaker than specific Job membership proof. An earlier `--edge-skip-compat-layer-relaunch`-only control still handed off and is not an established fix. Earlier descriptions that aggregate Job activity proves custody were too strong; these newer observations explicitly separate readiness, root identity and custody. Authority/prerequisite refinement from the subsequent ordinary-user controls: - Direct native observation of the WSL-launched Windows caller: elevated=true, administrator=true, integrityLevel12288 (high). The recovered ordinary fixture caller: elevated=false, administrator=false, integrityLevel8192 (medium), unchanged before/after each test. - With ordinary caller and **original arguments**, CDP is ready1775ms, browser PID106648 matches the still-live retained root. Owned cleanup succeeds and the exact endpoint is unavailable three times; profile removed/outerJob0. - Ordinary caller plus feature flag also passes (ready2291ms), so the flag is **not needed by the current evidence**. - Native CreateProcessW uses the caller security context; TokenOwner normalization does not lower elevation/integrity. Disabling AutoDeElevate under an elevated caller therefore does not establish ordinary browser authority. Actual browser token integrity remains unmeasured. The narrow correction is a shared explicit ordinary-user Windows fixture preflight, before site/profile allocation, with actionable refusal for elevated/non-ordinary callers. Follow the existing packaged-Ghidra verifier precedent and existing native caller-token observation; do not silently borrow desktop tokens or change caller authority inside the verifier. Run the audit through the separately established ordinary route. Preserve original browser arguments/sandbox, existing fail-closed early root-exit rejection and startup deadline. No startup-wait relaxation, feature flag or production CLI launch-policy change is justified. This issue concerns missing explicit fixture prerequisites/diagnostics under the elevated audit caller, not a reproduced failure with a normal ordinary caller. Regression: real Edge must report the still-live retained root as browser around the readiness query; cleanup must make that exact endpoint unavailable. Preserve spawn failure, zero/nonzero exit, signal, timeout and stale/late-port rejection. Rerun actual runtime, all nested source-map cases and composite CLI/MCP verification serially. Receipts for this pair: original6.50s/110.6MiB peak native Job commit/2.13s sampled family CPU/114.2MiB sampled family working set; feature-disabled4.99s/112.2MiB/2.36s/117.7MiB. BelowNormal, two logical CPUs,2GiB outer Job bound; PowerShell observer unmeasured. One pair does not establish general speed improvement. Full local evidence: `/tmp/rea-windows-e2e-20261013/results/edge-custody-*.stdout` and receipts. No profiles, binaries or ambient environment are published. Ordinary controls: original4.926s/110.8MiB peakJob/2.203s sampled CPU/115.0MiB sampled WS; flagged7.268s/130.6MiB/2.109s/114.6MiB; bothJob0. Actual ordinary unmodified runtime and all four nested-map workflows now pass: runtime70.576s/1101.7MiB peakJob/50.328s sampled CPU/1039.7MiB sampled WS; source-maps201.713s/792.4MiB/187.172s/948.9MiB. BothJob0 and native caller token unchanged. Source-map outerbudget600s explicitly accommodated the multi-case composite, but it completed below the prior300s ceiling. The original high-caller failures did not establish map defects.

bsakaguchi

2026-10-15 18:30:29 +00:00

closed this issue
added the
area: runtime

bug
labels

bsakaguchi commented

2026-10-15 18:30:31 +00:00

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Resolved on main by eca18e08a. The browser verifier entrypoints and shared lifecycle helpers now call requireOrdinaryWindowsVerifierCaller before fixture allocation. Rechecked tests/boundary/browser/browserProcessStartup.test.ts on current main b8510ee00 and inspected the upfront calls in the named scripts. This verifies the guard wiring and controlled startup behavior; a Windows browser host was not executed in this pass.

@morluto commented on GitHub (Oct 14, 2026): Resolved on main by eca18e08a. The browser verifier entrypoints and shared lifecycle helpers now call requireOrdinaryWindowsVerifierCaller before fixture allocation. Rechecked tests/boundary/browser/browserProcessStartup.test.ts on current main b8510ee00 and inspected the upfront calls in the named scripts. This verifies the guard wiring and controlled startup behavior; a Windows browser host was not executed in this pass.

bsakaguchi referenced this issue

2026-10-17 21:08:01 +00:00

[PR #1032] [MERGED] refactor(artifacts): move inventory and extraction into provider owners #2596

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1032

No description provided.

Rows
Columns