Merge main into the Valdi Web sync branch (resolve #148 conflicts)

[beaucollins]

What

Merges main into the Valdi Web sync branch (simon/260814-valdi-web), resolving the conflicts that block #148 from merging to main.

Why the conflicts exist

main and simon/260814-valdi-web have unrelated histories — zero shared commits, no merge base. So every file present in both trees with differing content surfaced as an add/add conflict (313 of them). They are an artifact of the missing common ancestor, not competing edits. Of the 313, 312 are real content differences (205 edited on both sides, 79 trimmed on head, 29 head-superset); only 1 is whitespace-only.

How it's resolved

All 313 conflicts take the sync branch's version — it's the authoritative 731-commit import the web build and tests were validated against, whereas main is a 14-commit snapshot whose divergences are stale dependency pins and superset-able infra. The resolved tree is byte-identical to the sync head for those files.

The 446 files that exist only on main are carried in unchanged by the merge (they already live on main).

Effect

After this lands on simon/260814-valdi-web, main becomes an ancestor of the sync branch, so #148 merges to main conflict-free.

For reviewers

Taking the sync side drops a few main-only changes to shared files — notably main's ASan nightly-sanitizer block in .bazelrc. Please confirm those are intentionally superseded, and review the 446 main-only files for any that the sync means to replace.

🤖 Generated with Claude Code

[github-actions]

Sensitive Files Detected

🔧 Build rules — Affects build rules for all Valdi consumers.

🧬 Compiler emit goldens regenerated — The Valdi compiler produced different output for the testdata corpus (e.g. a TypeScript bump or a transform change). Review the emit diff carefully and confirm it is intended — see tools/ci/compiler_goldens/README.md.

_{This is an automated notice. A maintainer will review after import.}

[github-actions]

📊 PR Size: size/XL

Total changes: 65035 lines (446 files)

Top files changed:

• npm_modules/cli/src/debugger/server.ts: +4639 -0
• npm_modules/cli/src/debugger/server.spec.ts: +4087 -0
• npm_modules/cli/debugger/devtools-panel.js: +3329 -0
• npm_modules/cli/src/debugger/devtoolsPanel.spec.ts: +3180 -0
• src/valdi_modules/src/valdi/web_renderer/test/LegacyWebDebuggerAdapter.spec.ts: +2000 -0
• npm_modules/cli/debugger/debugger.css: +1865 -0
• valdi/test/standalone_http/CurlHTTPRequestManager_tests.cpp: +1763 -0
• src/valdi_modules/src/valdi/valdi_test/test/DebuggerInputMessageHandler.spec.ts: +1390 -0
• npm_modules/cli/debugger/devtools-panel.css: +1318 -0
• src/valdi_modules/src/valdi/valdi_core/src/debugging/DebuggerInputMessageHandler.ts: +1264 -0

...and 436 more files

_{Size calculated as additions + deletions. Labels: XS (<10), S (<50), M (<250), L (<1000), XL (1000+)}

[semgrep-code-snapchat]

Semgrep identified an issue in your code:

actions/setup-java@v4 is a mutable action reference executed with cloud-related workflow permissions. If its tag is repointed, attacker-controlled code could run before the build and steal credentials or poison the Bazel cache.

More details about this

actions/setup-java@v4 uses the mutable v4 tag rather than an immutable commit reference. The action runs before Configure Bazel cache, setup_linux_env.sh, and sanitizer_tests.sh, so if the v4 tag is repointed or the action repository is compromised, the workflow could execute attacker-controlled Java setup code on the ubuntu-latest runner. That code could read available workflow variables and credentials, alter the checkout or build environment used by the Valdi ASan tests, and—because this workflow grants id-token: write—attempt to obtain an OIDC token and access any cloud role trusted by GCP_PROJECT_ID, WORKLOAD_IDENTITY_PROVIDER, or GCP_SERVICE_ACCOUNT.

A plausible attack is: (1) an attacker causes the v4 tag in actions/setup-java to point to a malicious commit; (2) the scheduled or manually dispatched valdi-sanitizer-tests workflow executes that commit during Setup Java 17; (3) the malicious action inspects the runner environment and workflow context, then requests an OIDC token or uses accessible credentials; (4) the attacker uses the obtained cloud access to read or modify the Bazel cache bucket associated with BAZEL_CACHE_BUCKET, potentially poisoning artifacts consumed by later builds. Because the tag can move without any change to this workflow, the workflow's reviewed dependency is not stable.

To resolve this comment:

✨ Commit fix suggestion

1. Replace the mutable actions/setup-java@v4 reference with the full 40-character commit SHA for the trusted actions/setup-java release, for example: uses: actions/setup-java@<40-character-commit-sha> # v4.
2. Verify that the commit SHA belongs to the official actions/setup-java repository and corresponds to the intended v4 release before applying it.
3. Keep the existing distribution and java-version inputs unchanged.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-snapchat]

Semgrep identified an issue in your code:

actions/checkout@v4 can silently change to attacker-controlled code. A compromised tag could execute on scheduled or manually dispatched runs with repository-read and OIDC permissions, exposing source code or trusted cloud access.

More details about this

actions/checkout@v4 uses the mutable v4 tag rather than an immutable commit. The action runs at the start of valdi-sanitizer-tests on a GitHub-hosted runner, and this workflow grants contents: read plus id-token: write; if the action owner or its release process repoints v4, a later scheduled run or manual dispatch could execute attacker-controlled action code before the repository steps run.

A plausible attack would be:

1. An attacker compromises the actions/checkout release path or obtains control of the v4 tag.
2. The next schedule run resolves actions/checkout@v4 to the attacker's commit instead of the expected checkout implementation.
3. That code executes with this job's permissions, reads the checked-out repository and available workflow context, and can request an OIDC token because id-token: write is enabled.
4. The attacker sends repository contents, the GITHUB_TOKEN, or a cloud credential exchanged from the OIDC token to an external server, potentially allowing source-code theft or access to trusted cloud resources.

The same mutable-reference risk also exists for actions/setup-java@v4 later in this workflow, although this finding is on the checkout step.

To resolve this comment:

✨ Commit fix suggestion

1. Replace the mutable checkout tag with the full commit SHA for the trusted actions/checkout v4 release:
   uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4

2. Pin the external actions/setup-java@v4 step to the full 40-character commit SHA for the approved v4 release, retaining a version comment such as # v4.

3. Leave the local action reference uses: ./.github/actions/bazel-cache unchanged; local paths are not mutable external dependencies.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-snapchat]

Semgrep found 60 internal-sensitive-strings findings:

• tools/ci/compiler_goldens/binding_lang_swift/android/release/src/binding_lang_swift.kt.golden
  • L1 - Triage
  • L3 - Triage
  • L4 - Triage
  • L7 - Triage
  • L15 - Triage
• tools/ci/compiler_goldens/binding_lang_swift/.valdi_build/compile/typescript/dumped_symbols/binding_lang_swift/compilation-metadata.json.golden
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
• tools/ci/compiler_goldens/binding_lang_objc/android/release/src/binding_lang_objc.kt.golden
  • L1 - Triage
  • L3 - Triage
  • L4 - Triage
  • L5 - Triage
  • L6 - Triage
  • L7 - Triage
  • L8 - Triage
  • L9 - Triage
  • L10 - Triage
  • L11 - Triage
  • 4 more - Triage
• tools/ci/compiler_goldens/binding_lang_objc/.valdi_build/compile/typescript/dumped_symbols/binding_lang_objc/compilation-metadata.json.golden
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
• tools/ci/compiler_goldens/binding_lang_both/android/release/src/binding_lang_both.kt.golden
  • L1 - Triage
  • L3 - Triage
  • L4 - Triage
  • L5 - Triage
  • L6 - Triage
  • L7 - Triage
  • L8 - Triage
  • L9 - Triage
  • L10 - Triage
  • L11 - Triage
  • 4 more - Triage
• tools/ci/compiler_goldens/binding_lang_both/.valdi_build/compile/typescript/dumped_symbols/binding_lang_both/compilation-metadata.json.golden
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage
  • L1 - Triage

This literal might contain a Snapchat internal reference that should not be committed to open-source repositories.

Fix: Please replace / remove the string to avoid committing it to open-source repositories.