fix(s3): adapt CopyObject to multistore's copy-source path mapping

[alukach]

Bumps multistore to 0.7.1 and adapts this proxy to the copy-source handling it introduces.

Why

CopyObject names its source in the x-amz-copy-source header rather than the URL, in client coordinates (/account/product/key). This deployment is path-mapped, so the registry only knows mapped bucket names (account:product) — an unmapped source resolves to a bucket it has never heard of and the copy fails with 404 NoSuchBucket. That affects the server-side CopyObject support landed in 97d5121.

multistore 0.7.1 provides the mechanism for this (#128), but it is opt-in: RequestInfo::with_copy_source takes a mapped value that the host app must supply. This wires it up.

The bump also picks up #129, which authorizes a versioned copy-source against its version.

Changes

• Cargo.toml / Cargo.lock — multistore crates to 0.7.1, from crates.io with checksums.
• object_path::mapped_copy_source — maps the header through PathMapping::rewrite_copy_source, returning None for a non-copy request or an unmappable value. Lives in object_path because that module is deliberately wasm-free and so can be unit-tested natively, the lib being cdylib with test = false.
• src/lib.rs — passes the mapped value via with_copy_source. The client signed the original header, so it is left untouched and signature verification still uses it as sent; only the value passed alongside differs.

Tests

The mapping is pinned natively in tests/object_path.rs: the account/product fold, leading-slash normalization, nested keys, versionId and percent-encoding preservation, and both None cases.

Natively rather than through an integration test, because an integration test cannot detect this regression: federation is attempted against the destination before the copy source is resolved, so in CI — where the throwaway signing key means federation never succeeds — a copy fails identically whether or not the mapping is wired up. This was verified, not assumed.

Copy-source authorization — a caller holding write on the destination must not be able to read a product they aren't entitled to via CopyObject — is asserted in tests/test_federation.py, the deployed-environment suite. Same reason: in CI the destination write never succeeds, and AccessDenied is itself a federation error code, so the assertion would pass without proving anything. It is dormant and skips until both FEDERATION_WRITE_PRODUCT and a caller token are supplied, and skips cleanly otherwise; staging.yml gains boto3, the FEDERATION_WRITE_PRODUCT passthrough, and a step minting the caller as a GitHub Actions OIDC token — short-lived and per-run, with nothing stored. This anticipates registering GitHub as a valid IdP with Source so products can accept writes from GitHub Actions.

It stays dormant until two things land: the deployment's AUTH_ISSUER must accept GitHub's issuer, which is a code change and not only config — src/config.rs:80 reads AUTH_ISSUER as a single String, unlike the comma-separated AUTH_AUDIENCE at src/config.rs:87 — and FEDERATION_TEST_AUDIENCE must name the audience Source expects. Until both, no token is minted and the test skips.

Two integration tests in tests/test_writes.py cover what that layer can genuinely show, CopyObject having had no coverage there at all: test_anonymous_copy_is_denied (a copy is a write, so it dies at the authz gate) and test_copy_reaches_the_federation_seam (a copy is parsed and dispatched as a copy, and fails closed).

Verification

• cargo test — 73 pass across 8 suites (was 69)
• cargo check --lib --target wasm32-unknown-unknown — clean
• Local run against stub API + wrangler dev; credentialed tests need a GitHub OIDC token and run in CI

🤖 Generated with Claude Code

[claude]

Claude finished @alukach's task in 3m 50s —— View job

---

Review

• Gather context (diff, changed files)
• Review src/object_path.rs mapping logic
• Review src/lib.rs wiring
• Review tests and CI workflow changes
• Post final review

✅ No blocking issues — safe to merge.

• src/object_path.rs:42-50 — mapped_copy_source correctly returns None both for absent headers and unmappable values, and the docstring correctly identifies why that fallback is safe (an unmappable source fails on its own merits rather than resolving to an invented bucket). src/lib.rs:322,334 reuses the same mapping instance already built for MappedRegistry, so the copy-source fold uses the identical account/product rule as the rest of the request — no drift between the two mappings.
• src/lib.rs:322-334 — the client-signed x-amz-copy-source header itself is left untouched in parts.headers; only the mapped value is threaded through with_copy_source, so SigV4 verification still runs against what the client actually signed. This matches the stated intent and is the crux of the fix.
• tests/object_path.rs — good coverage: bucket folding, optional leading slash, nested keys, versionId/percent-encoding preservation, and both None cases (absent header, too few segments). This is the one test tier that can actually catch a regression here, per the PR's own reasoning about the federation seam masking it in integration tests — confirmed by reading tests/test_writes.py:420-431, which documents that it was verified by deleting the wiring and watching the integration test still pass.
• .github/workflows/staging.yml:71 — ${{ vars.FEDERATION_TEST_AUDIENCE }} is interpolated directly into the run: shell block rather than passed through env:. Normally this pattern is flagged as a script-injection risk, but this workflow only triggers on push to main (no pull_request/fork input), and vars.* are maintainer-controlled, not attacker-controlled — so this is a low-risk style nit, not a blocking issue. Optional hardening if you want to preempt a future linter flag:

  env:
    AUDIENCE: ${{ vars.FEDERATION_TEST_AUDIENCE }}
  run: |
    set -euo pipefail
    token=$(curl -sSf -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
      "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=$AUDIENCE" \
      | jq -r '.value')

• The new id-token: write permission is scoped to the federation-smoke job only (least privilege), the minted token is masked before being written to GITHUB_ENV, and the mint step is correctly gated behind FEDERATION_TEST_AUDIENCE so it stays fully inert until that variable is set.
• tests/test_federation.py's new test_copy_source_authorization_is_enforced correctly accepts 401/403/404 as success (a source-side auth failure could plausibly surface as any of the three depending on whether the check happens before or after existence), and its skip condition doesn't require FEDERATION_TEST_KEY, falling back to a literal "any-key" — reasonable since the assertion is about denial, not object content.
• tests/test_writes.py's new test_anonymous_copy_is_denied expecting 403 is consistent with the existing convention used by other anonymous-write-denied tests in the same file (e.g. line 128).

I wasn't able to run cargo test/cargo check in this sandbox (network access for crate resolution requires approval that isn't available in this context), so I relied on static reading plus the PR's own stated verification (73 tests passing, cargo check --lib --target wasm32-unknown-unknown clean). Nothing in the diff contradicts those claims.

[github-actions]

🚀 Latest commit deployed to https://source-data-proxy-pr-198.source-coop.workers.dev

• Date: 2026-07-28T00:24:49Z
• Commit: 923e3e0