mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
Eric Burke
ad2012d645
## Why The public Codex release workflow needs to sign and notarize macOS binaries and DMGs without placing the Developer ID private key in GitHub. This moves the private-key operation behind the protected `codesigning` environment and uses GitHub OIDC with Azure Key Vault PKCS#11, while preserving the existing external `build_unsigned` / `promote_signed` fallback. ## What changed - Add a reusable AKV PKCS11 setup action that authenticates to Azure with OIDC, downloads pinned signing tools, verifies their SHA-256 digests, and loads the public signing certificate from Key Vault. - Replace the legacy macOS signing action with scripts that support AKV-backed `rcodesign`, notarize signed binaries and DMGs, and staple DMG notarization tickets. - Restructure `rust-release.yml` so macOS builds produce unsigned artifacts first, protected jobs perform signing and notarization, macOS runners package and verify the results, and release publishing waits for verified artifacts. - Preserve the manual external-signing handoff flow and make manual-mode conditions explicit. - Move the Codex entitlements file alongside the signing scripts and update CODEOWNERS for the new signing surfaces. ## Verification - [Live protected signing workflow run](https://github.com/openai/codex/actions/runs/26903610631) completed successfully for both macOS architectures, including binary signing/notarization, DMG signing/notarization, and final artifact verification. - Downloaded both signed DMGs and independently verified their checksums and strict signatures. - Confirmed `xcrun stapler validate` succeeds and Gatekeeper accepts both DMGs as `Notarized Developer ID`. - Mounted both DMGs and confirmed the contained `codex` and `codex-responses-api-proxy` binaries have valid Developer ID signatures for the expected architectures. --------- Co-authored-by: shijie-openai <shijie.rao@openai.com>
ad2012d645
ยท
2026-06-03 20:34:51 -07:00
History
Workflow Strategy
The workflows in this directory are split so that pull requests get fast, review-friendly signal while main still gets the full cross-platform verification pass.
Pull Requests
bazel.ymlis the main pre-merge verification path for Rust code. It runs Bazeltestand Bazelclippyon the supported Bazel targets, including the generated Rust test binaries needed to lint inline#[cfg(test)]code.rust-ci.ymlkeeps the Cargo-native PR checks intentionally small:cargo fmt --checkcargo shearargument-comment-linton Linux, macOS, and Windowstools/argument-comment-lintpackage tests when the lint or its workflow wiring changes
Post-Merge On main
bazel.ymlalso runs on pushes tomain. This re-verifies the merged Bazel path and helps keep the BuildBuddy caches warm.rust-ci-full.ymlis the full Cargo-native verification workflow. It keeps the heavier checks off the PR path while still validating them after merge:- the full Cargo
clippymatrix - the full Cargo
nextestmatrix via per-platform archive-backed shards - Windows ARM64 nextest archives cross-compiled on Windows x64, then replayed on native Windows ARM64 shards
- release-profile Cargo builds
- cross-platform
argument-comment-lint - Linux remote-env tests
- the full Cargo
Rule Of Thumb
- If a build/test/clippy check can be expressed in Bazel, prefer putting the PR-time version in
bazel.yml. - Keep
rust-ci.ymlfast enough that it usually does not dominate PR latency. - Reserve
rust-ci-full.ymlfor heavyweight Cargo-native coverage that Bazel does not replace yet.