Pin and verify mcp-publisher before executing it in the OIDC release job

[dgenio]

Problem

The PyPI portion of .github/workflows/publish.yml is deliberately hardened: third-party Actions are pinned to immutable SHAs, PyPI uses Trusted Publishing/OIDC, and build provenance is attested.

The subsequent MCP Registry job breaks that same trust model:

curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_...tar.gz" | tar xz mcp-publisher
chmod +x mcp-publisher
./mcp-publisher login github-oidc
./mcp-publisher publish

The job has id-token: write, yet it resolves releases/latest at runtime and immediately executes the downloaded binary without pinning its release identity or verifying its artifact digest/signature.

A new upstream release can therefore change the executable used by an unchanged ContextWeaver release workflow. That is inconsistent with the workflow's own immutable-dependency policy and creates unnecessary release-path supply-chain risk.

Goal

Make the MCP Registry publisher an immutable, reviewable dependency with artifact-integrity verification before it runs in an OIDC-authorized job.

Proposed changes

• Pin an explicit reviewed mcp-publisher release version rather than releases/latest.
• Download the exact platform artifact for that version.
• Verify an upstream-published checksum/signature/provenance before extracting/executing it. If upstream does not publish a suitable verification artifact, record the expected SHA256 in the repository/workflow and update it through a reviewed dependency PR.
• Fail closed when verification cannot be completed.
• Keep GitHub OIDC authentication; do not replace it with a long-lived registry credential.
• Add a maintenance path (Dependabot-equivalent issue/automation or a documented periodic check) so the pin can be intentionally refreshed.
• Add an explicit timeout-minutes to the registry publish job while touching the release path; its propagation retry loop is bounded internally but setup/download/auth should also have an outer ceiling.

Acceptance criteria

• The release workflow contains no releases/latest resolution for an executable publisher.
• The exact publisher version is visible/reviewable in source.
• The downloaded artifact is verified before execution.
• Verification failure prevents OIDC login/publish.
• Registry publishing still uses GitHub OIDC and the existing bounded PyPI-propagation retries.
• Updating the publisher version necessarily produces a repository diff that can be reviewed.
• The registry publish job has an explicit, generous job timeout.

Non-goals

• Replacing the MCP Registry publisher implementation.
• Storing long-lived registry credentials.
• Removing the retry needed for PyPI metadata propagation.

Priority

P1 release/supply-chain hardening because this executes externally downloaded code in a job with federated publishing authority.

[dgenio]

Implemented in release PR #842: the MCP Registry publisher is now pinned to official v1.7.9, the reviewed Linux-amd64 SHA256 is committed, the tarball is downloaded from the exact version URL with fail/retry semantics, sha256sum --check --strict runs before extraction/execution, releases/latest is gone, and OIDC login happens only after the verified binary passes a smoke check. Keeping this issue open until the v0.18.1 publish path runs successfully end-to-end, so implementation and real release validation remain distinct.