Fail closed on Chromium sandbox launch failure
HA
4d ago+1145+1145+0123456789012345678901234567890123456789-571-571-012345678901234567890123456789
Fixes #449
Summary
- Keep Chromium sandboxed by default and fail closed instead of retrying with
--no-sandbox. - Make sandbox launch errors actionable on one-shot PNG exports and persistent browser sessions.
- Use explicit sandbox opt-outs only for trusted repository fixtures and synthetic data; document the repository-owned callers.
- Audit universal Python lock exports across platform and Python marker variants, and execute a mapped handler for every inventoried lock.
- Keep the breaking-change note focused on the Chromium behavior change.
Validation
- Export tests: 188 passed, 3 Windows-specific cases deselected (macOS path assumptions and CRLF text-write behavior).
- Review regressions: 6 passed; Ruff, formatting, workflow validation, lock inventory, both uv lock checks, and
git diff --checkpassed. - Local root and docs universal-lock pip-audit: no known vulnerabilities. The docs audit skips unpublished/local Reflex packages unavailable on PyPI.
- Hosted head
de0801a: Test (Rust + Python + JS), Dependency security audit, Docs, changelog, and CodSpeed passed. Two unrelated Matplotlib gallery shards were still installing system dependencies with no failures reported. - Follow-up head
5d107fbis awaiting maintainer approval for GitHub Actions to run on this fork PR.
Summary by CodeRabbit
- Security
- Image exports and persistent browser sessions now fail closed when Chromium cannot start with its sandbox enabled; they no longer retry without it. Disabling the sandbox requires an explicit opt-in and should be limited to trusted HTML.
- Automated dependency audits now cover Python, Rust, npm, and Bun dependencies, including documentation and benchmark environments. Checks verify that tracked lockfiles are accounted for, run on a schedule, for relevant pull requests, or on request, and apply severity thresholds by ecosystem.