[nox]

Publishing to crates.io is now a manually triggered workflow that requires a merged one-commit release PR whose merge commit remains reachable from master. It validates the four crate versions, creates an immutable tag, publishes boring-sys, and then creates or reuses a non-latest GitHub Release. Each crate archive is checksum-verified against crates.io, and the Release body is updated after each crate with a link to its crates.io version. It becomes the latest release after all stable crates succeed; prereleases never become Latest. A partially completed release can be rerun with the same inputs. The repository README documents the process and the master-only crates-io environment policy. Pushing a tag alone does not publish a release.

[clanky-the-clanker]

💬 Approved with comments — The workflow is well guarded: inputs pass through env and are validated by regex, permissions are minimal, actions are pinned to SHAs, and the release commit and tag are re-verified. One non-blocking README wording issue about when a release becomes Latest.

Findings: 1 suggestion

_{The decision is advisory: this comment never approves, blocks or requests changes on the pull request.}

🔧 Fix with your agent

Paste the following into your coding agent to investigate and fix these issues.

Fix the following code review issues found in pull request #541.

Before making changes, review each issue and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g., the fix would require disproportionate changes
  for minimal ROI, or the finding is factually incorrect), explain why
- If you need to clarify something before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

## SUGGESTION (1)

### [Documentation] README says a completed release always becomes Latest, but publish.yml:470-475 uses make_latest=legacy when the current Latest release has a higher version; reword the README to state that exception.
- **File:** README.md:26

---

📝 Documentation: 💬 1 suggestion

The README overstates when a completed release becomes Latest.

Recommendation: 💬 Optional Nits

• [SUGGESTION] README says a completed release always becomes Latest, but publish.yml:470-475 uses make_latest=legacy when the current Latest release has a higher version; reword the README to state that exception. (README.md:26)

View full review

• README.md:26 says that after all crates publish, "the GitHub Release becomes the latest release." That isn't always true. At .github/workflows/publish.yml:470-475, the workflow sets make_latest=legacy when the current Latest release has a higher version, so a backport or patch release on an older line will not become Latest. Suggested wording: "becomes the latest release unless a higher version is already Latest."

---

✅ All other checks passed

🚀 Release: ✅ LGTM

Risk: Low. The release flow is gated on a merged release PR, validated versions, an immutable tag and checksum-verified reruns.

---

🔒 Security: ✅ LGTM

No exploitable issues found in .github/workflows/publish.yml. Points checked:

• Input handling: pr_number and expected_version reach the scripts through env, not by interpolating them into the script text. Both are validated with strict regexes, and publish depends on validate.
• Permissions: the workflow default is permissions: {}. contents: write and id-token: write are granted only to publish, and validate is read-only.
• Token exposure: the crates.io token is scoped to the publish steps. Packaging and publishing use --no-verify, so build scripts don't run while the token is available.
• Action pinning: actions are pinned to commit SHAs, and checkout uses persist-credentials: false.
• Release commit integrity: both jobs re-verify that the merge commit is reachable from master and that any existing tag points at it.
• Environment policy: publishing relies on the crates-io environment's master-only policy, which must be configured as the README describes.

---

📖 AGENTS.md: ✅ LGTM

No AGENTS.md concerns for this change. The release process is documented in the README.

---

📋 Code Quality: ✅ LGTM

No code quality issues found in .github/workflows/publish.yml.

---

⚡ Performance: ✅ LGTM

No performance concerns.

---

_{Reviewed commit: 57d4c487}

[nox]

The crates-io environment currently permits v* tags, while this workflow runs from master and creates the release tag only after publication. The environment policy therefore needs to permit master rather than only v* tags.