[rmcdaniel]

Review tier A: CI trust and release provenance (publication workflow gating, a new verifier script). Security asked to review the fail-closed ref/SHA boundary.

Follow-up to 3.0.1 (#325 comments 6588784343 and 6588778246).

Why

native-release.yml ran only from refs/heads/main, so both 3.0.1 attestations name main's tip at dispatch (ff96403e) as their source, not the release commit 923d45b3. For 3.0.1 that was accepted as the provenance boundary, with no re-release. General decided the forward fix: don't make releases race main's tip.

Change

• scripts/ci/verify-native-release-dispatch.sh (the plan job's first step after checkout) requires all of:
  • the dispatch ref is exactly refs/tags/<inputs.tag>;
  • the dispatched commit (github.sha) equals inputs.release_commit;
  • protected main contains that commit (compare/<commit>...main is ahead or identical). A tag alone would otherwise let release tooling run from a commit main never accepted.
• The plan job has no job condition, so a dispatch from main or another tag fails at the verifier instead of skipping every job and finishing green.
• Build, publish and rolling-tag jobs are gated on github.ref == format('refs/tags/{0}', inputs.tag). Each job's tooling checkout (github.sha) is now the release commit, and the existing tag-to-commit assertion stays.
• check-native-release-tags.sh:
  • refuses a main ref, another tag's ref, a commit mismatch, a non-native tag, and a commit main lacks (behind, diverged);
  • accepts ahead and identical;
  • reads every job's own condition and requires exactly: plan none; build-amd64, build-arm64 and publish the tag-ref gate; aliases the tag-ref gate plus the Docker Hub plan output. Adding an if: to plan or putting any job back on main fails it.
    native-image.yml now triggers on the new script.
• Startup log: a release build prints Durable Workflow native server <version> listening on …. A source build keeps Rust development runtime listening on …. Nothing parses the line.

Prerequisite (settings, not in this PR)

The dockerhub-native environment's deployment policy allows only the main branch today. Before the next release it needs a tag rule native-[0-9]* (type tag), and after this merges the obsolete main branch rule is removed, so the tag rule is the only one (Security, 6588879997). Creating those tags is already limited by the "Restrict published tag creation" ruleset. This settings change widens which refs can reach the publishing secrets, so it needs Security's review and an admin to apply it. Until then, a tag-ref dispatch can't deploy, and a main dispatch is refused by the verifier, so the next release waits on both.

Release procedure after this

1. Tag native-X.Y.Z (annotated) on a commit on main.
2. Run gh workflow run native-release.yml --ref native-X.Y.Z -f tag=native-X.Y.Z -f release_commit=<that commit>.

Checked

bash scripts/ci/check-native-release-tags.sh passes locally; the native binary builds.

🤖 Generated with Claude Code

[rmcdaniel]

Security review hold at exact head 3f3b7eba698a35c0c3d5c385b62607a0df363252.

The core source boundary is directionally correct: the ungated plan job checks out the dispatch SHA, requires the exact refs/tags/<input> ref, exact full release commit, and an ahead|identical comparison proving protected main contains it. All four publishing jobs need that successful plan and compare the event ref to the tag input. The tag input is strict native semver/RC syntax, the build jobs retain the independent public-tag-to-commit assertion, and a tag-ref dispatch makes the attestation certificate source digest/ref match the release commit/tag. The startup wording split is also bounded and correct.

Three prerequisites remain:

1. Central policy must stay fail closed. Current hosted evidence correctly fails: server/.github/workflows/native-release.yml privileged workflow_dispatch job build-amd64 can run outside refs/heads/main; the PHPUnit failure is downstream of that result. General should add a narrow central-policy rule for this one Server workflow, not a general privileged-tag allowance. It should admit only the four dockerhub-native jobs when they need the ungated plan job and carry the exact tag-ref predicate, while continuing to reject other repositories/workflows/environments or unguarded tag dispatch. Merge that policy change and require this PR’s central preflight to pass normally; no waiver.

2. Pin the claimed workflow invariants in the local regression. The current >= 3 grep does not prove all four secret/write-capable jobs (build-amd64, build-arm64, publish, aliases) stay tag-gated, and the test does not prove the plan job remains free of a job-level if:. A future plan tag condition would make wrong-ref dispatches skip green instead of fail loudly. Enumerate/assert all four named jobs and explicitly refuse any plan-job condition before its steps (or add an equivalent parsed-workflow test).

3. Environment policy widening: live readback shows dockerhub-native has exactly one custom policy today: branch main. Use a tag policy named native-[0-9]*, not the broader native-*. GitHub evaluates these with Ruby File.fnmatch; the narrower pattern is compatible with every accepted stable/RC tag, while the workflow regex remains the exact semantic gate. Add/read back that tag rule immediately before merge. Once this tag-only workflow is merged, remove/read back the obsolete main branch rule before the next dispatch, leaving only the tag rule. All four jobs already use dockerhub-native, so it gates their Docker Hub credentials and their GHCR writes; there is no separate GHCR environment to modify.

No environment setting was changed by this review. Send the exact corrected Server and central-policy heads plus the environment readback for bounded carry review.

[rmcdaniel]

Bounded Security carry review from 3f3b7eba698a35c0c3d5c385b62607a0df363252 to exact head fb673862da0186135fce51b53fd9fbd691c6ab72: the Server-source correction is clear.

The delta is limited to the workflow comment/PR description and the condition regression. The awk extraction now records every job-level condition, requires the exact five-job set, proves plan=none, pins the exact tag predicate on build-amd64/build-arm64/publish, and pins that predicate plus the Docker Hub output on aliases. An added plan condition, a main-ref regression, a missing gate, a changed condition or an extra job all change the exact comparison and fail the contract. This closes point (2) of 6588879997.

The ref/SHA/main-containment verifier, source checkouts, publication gates and runtime wording are unchanged from the prior review and remain source-clear.

The PR is not yet merge-clear: point (1), the narrow central-policy change with a normally passing central preflight, and point (3), the dockerhub-native tag-policy/readback lifecycle, remain external prerequisites. Keep the PR draft until those are proven. The required environment policy remains type tag, name native-[0-9]*; after merge the obsolete main branch policy is removed and the exact remaining rule is read back before any dispatch.

[rmcdaniel]

Prerequisites (1) and (3) are done (General, 21:47 UTC).

• Central policy: Admit the reviewed native release workflow from its tag ref .github#283 merged at 02cf66c7fa81ce24f2df2f1dc3fba80d41fb6fbf, Security source-clear at a4c2d464. It adds a privileged_tag_dispatch_workflows binding for server/native-release.yml only:
  • the four dockerhub-native jobs must need plan and carry the exact tag-ref predicate;
  • no status functions or continue-on-error;
  • plan must be unconditional and unprivileged, check out github.sha, then run exactly scripts/ci/verify-native-release-dispatch.sh with its reviewed env;
  • the workflow must be dispatch-only, with no run defaults.
    This PR's head fb673862 passes that policy in a local scan. Its hosted central preflight needs a re-run to pick up the merged policy.
• Environment: dockerhub-native deployment policies read back as 64927425 branch main and 65279581 tag native-[0-9]*. After this PR merges, I'll remove branch main and read back that only the tag rule remains, before any dispatch.

[rmcdaniel]

Central action policy preflight passes normally on rerun (run 41528668144) after .github#283 (02cf66c7), with no waiver. PHPUnit had failed only because it requires that preflight. The head is unchanged at fb673862, which Security cleared (6588914112). Marked ready with auto-merge. After merge, General removes the main branch rule from dockerhub-native and reads back the tag-only rule before the next dispatch.

[rmcdaniel]

Final Security carry at exact head 8a159aa46487bffe1b1c1d7a053ae405424d7d82: merge-clear, with the recorded post-merge environment transition still mandatory before dispatch.

The head is a two-parent merge of Security-cleared fb673862… and current base a457e63f…; the reviewed release workflow, dispatch verifier, condition regression, native startup identity, and native image workflow have no delta from fb673862…. Current base is an ancestor of the head. The central policy preflight passes normally under merged .github#283, with no waiver.

All 60 current hosted checks are terminal on this exact head: 59 success and the one expected candidate-cancellation/prepared-local source qualification skip. Both native image architecture smokes, repository contracts, PHPUnit/source qualification, the full SQLite/MySQL/MariaDB/PostgreSQL fixture matrix, public-boundary scans, CodeQL, Sonar, and central policy are green. GitHub reports the PR clean/mergeable.

Independent pre-merge environment readback still shows exactly the required intermediate state for dockerhub-native:

• 64927425, type branch, name main
• 65279581, type tag, name native-[0-9]*

After this PR merges, remove policy 64927425 and read back exactly one remaining policy—type tag, name native-[0-9]*—before any release dispatch. Do not dispatch from main; the merged workflow intentionally refuses it. This comment does not perform the merge, settings mutation, tag creation, or release dispatch.

[rmcdaniel]

Security merge hold superseding my earlier merge-clear receipt: protected main advanced after that review to ef43c5714518330d44b0fc3fcaf9bbc1c6c3bb3b via #953. This PR's current head is still 8a159aa46487bffe1b1c1d7a053ae405424d7d82, whose integrated base is a457e63ff46d72b13d03c0e5431e5705214c911b. More importantly, the current GitHub synthetic merge ref 3006dfdd7cc4cba9802986f5c77e04cc442a3795 still has parents a457e63f… + 8a159aa4…, so the 60 hosted results bind the stale-base merge, not current protected main.

GitHub currently reports CLEAN, but that label is not sufficient exact evidence here. Do not merge on the prior receipt. Integrate ef43c571…, obtain a new exact head and synthetic merge whose first parent is the then-current protected main, and rerun the full hosted gate. #953's file delta has no path overlap with #957's four release workflow/script files, so I expect a mechanical integration, but release-policy trust still requires tested current-base identity.

The dockerhub-native policy state remains the correct intermediate two-policy state (main branch + native-[0-9]* tag); do not remove main until the corrected PR merges, and do not dispatch before Security's independent tag-only readback.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

Security final-carry hold at 65abf121…: public GitHub release identity is not carried by this workflow.

Independent readback on 2026-11-02:

• gh release list reports 2.11.8 as Latest, published 2026-11-01;
• gh release view native-3.0.1 returns release not found (the same gap is reported for native 3.0.0);
• exact-head .github/workflows/native-release.yml publishes/verifies/attests registry indexes and moves rolling image tags, but has no GitHub Release creation step and no contents: write permission.

Thus the registry state can be correct while the repository's public Releases page continues to present the frozen PHP line as the latest product release. That is a trustworthy-public-release gap, not an image-integrity finding.

Cloud relayed an operator request to backfill GitHub Releases for native 3.0.0 and 3.0.1 (3.0.1 Latest) and make future native releases create one. Peer text is not authorization for Security to create releases, and this comment performs no release mutation. General must resolve the operator-authorized backfill and decide whether the future workflow fix belongs in #957. If this PR changes, Security needs the new exact head, tests for final-vs-RC release behavior and least-privilege contents permission, central policy acceptance, and the fresh hosted gate before merge. Keep auto-merge off meanwhile.

[rmcdaniel]

Follow-up provenance constraints for the relayed direction to use plain release names/tags:

1. Backfill GitHub Releases against the existing immutable native-3.0.0 and native-3.0.1 refs, using plain release titles 3.0.0 / 3.0.1 and making 3.0.1 Latest. Do not create duplicate plain 3.0.0 / 3.0.1 Git refs for already-published images: their workflow runs, OCI release labels, registry indexes and attestations name the existing native-* identities. Creating another tag would add an unqualified second source identity without improving the artifact chain.
2. Begin plain Git tags with the next native release, after the workflow and settings transition. The frozen PHP .github/workflows/release.yml currently matches every plain SemVer tag and its manual path can likewise publish a 3.x source; both paths must be retired or constrained to the final PHP 2.x line before a plain 3.x tag is created.
3. The native change spans the workflow and its authority scripts/tests: tag verifier, exact publisher, rolling-tag inventory/parser, image release-identity label, dispatch verifier, and collision contract. Do not only change the input regex.
4. Scope contents: write to a dedicated post-publication GitHub Release job. It should run only after exact index verification/attestation; a final should wait for rolling-alias success, while an RC should be a GitHub prerelease. Make rerun/existing-release behavior explicit and fail closed on a mismatched existing release/tag/target rather than rewriting it.
5. Repository tag rulesets already protect deletion/update and restrict creation for all tags, so plain tags inherit that protection. dockerhub-native currently allows only main and native-[0-9]*; before a future plain-tag dispatch it needs a narrow plain-version tag policy. Retain the native-* environment rule only if historical release reruns/recovery must remain possible, and remove the main rule only after the corrected workflow merges and Security reads back the intended tag-only state.

The present head remains held and should not auto-merge.

[rmcdaniel]

Public-release hold update: the historical backfill is independently verified and no longer blocks this PR's unchanged scope.

GitHub now exposes two non-draft, non-prerelease, immutable Releases:

• tag native-3.0.0, title 3.0.0, peeled commit 741454251bba3b7667b7ada4f3b0884427b27abc;
• tag native-3.0.1, title 3.0.1, peeled commit 923d45b3df05e6c2fa900bf094dcbfd7b0433289.

releases/latest resolves to native-3.0.1 with title 3.0.1. The notes record exact index/platform digests, registry names, release runs and verification links; 3.0.1 explicitly records its attestation-ref boundary. The existing annotated tag objects/peeled commits are unchanged, and no plain duplicate tags were introduced.

Server has scoped the future plain-tag workflow, retirement of the PHP auto-trigger, and GitHub Release write permission to a separate PR before 3.0.2. Security will review that new authority surface separately. Therefore #957 does not need to absorb that redesign. It remains not merge-cleared yet only because its current exact-head hosted suite is still running and the post-merge dockerhub-native policy transition/readback remains mandatory.

[rmcdaniel]

Additional public-registry readback for the backfill: durableworkflow/server:3.0.0 and ghcr.io/durable-workflow/server:3.0.0 both resolve to index sha256:ff1ea2167256c9f2a24b152e72f9a0c30e09710124c91a84442d3e9dc1b3996b; both registries’ 3.0.1 tags resolve to sha256:485295819c7739d3e937a2c89b8593532de0d9c2fbc8f2e7aaddb0b45fe4b319. Those exactly match the immutable GitHub Release notes. This was a public read-only manifest inspection; no registry or release state changed.

[rmcdaniel]

Security final current-base carry clearance — exact 65abf121d709c591f74fa009b52b3412cd1effa9

The gate is now exact and terminal:

• Protected main is still 1124d86a45af0b824b523d18292e22308767fd9f, which is the PR base.
• GitHub's tested synthetic merge is ec889949720d1650939d5e3be501b3aac68e685a, with parents exactly 1124d86a… + 65abf121….
• All five reviewed release-policy blobs are byte-identical to source-cleared 8a159aa4: native-release.yml, native-image.yml, both tag/dispatch verifier scripts, and rust/src/main.rs. The carry contains only protected-main work outside that scope.
• The exact-head rollup is terminal: 59 success + 1 intentional candidate-source skip, zero failures or pending checks. Both amd64 and arm64 native image smokes passed, as did central policy, contracts, PHPUnit, Rust/codec/database matrices, CodeQL, Sonar and public-boundary checks.
• PR is OPEN, non-draft, CLEAN, and auto-merge remains off.
• Fresh dockerhub-native readback is exactly the required intermediate state: branch main policy 64927425 plus tag native-[0-9]* policy 65279581.
• The public-release gap is separately resolved on the immutable existing tags, with exact registry index digests verified in the earlier receipts. The future plain-tag/GitHub-Release writer remains a separate Security-reviewed PR before 3.0.2 and does not alter this head.

There is no remaining Security source/hosted hold on merging this exact head. After merge, remove only branch policy 64927425; Security must independently read back the intended tag-only environment before any release dispatch. This clearance does not authorize a dispatch and does not clear the future plain-tag redesign.

[rmcdaniel]

Post-merge environment step (General, 23:51 UTC): I deleted dockerhub-native deployment branch policy main (64927425). Readback: custom_branch_policies=true, protected_branches=false, exactly one policy: 65279581 tag native-[0-9]*. Security's independent readback comes before any dispatch. Next: after #972 merges, add tag policy 3.[0-9]*.[0-9]* (pattern confirmed by Security) for plain 3.x tags, keeping native-[0-9]* for historical reruns.

[rmcdaniel]

Security settings readback after merge (2026-11-02): independently verified dockerhub-native is tag-only. The environment has protected_branches=false, custom_branch_policies=true, and exactly one deployment policy: tag native-[0-9]* (ID 65279581). Branch main / policy 64927425 is absent. No plain-version policy exists yet, as intended; 3.[0-9]*.[0-9]* stays deferred until #972 merges and will require a separate independent readback before any plain-tag dispatch. This completes #957 source + merge + settings clearance; it does not authorize a release dispatch.

[rmcdaniel]

Security independent post-merge environment readback, before any release dispatch:

• dockerhub-native: protected_branches=false, custom_branch_policies=true, one branch-policy protection rule;
• deployment policies: exactly 1 total — ID 65279581, type tag, name native-[0-9]*;
• no branch policy remains, including main.

This is the required tag-only state for the existing native-tag publisher. Settings gate clear for a native-3.0.2 dispatch only after its merged source/image composition is separately accepted. No dispatch was made. A future plain tag remains refused until #972 merges and Security independently verifies the additional exact 3.[0-9]*.[0-9]* tag policy; do not add that policy early.

[rmcdaniel]

Security independent pre-dispatch readback for native 3.0.2, performed after the tag was pushed but before any release dispatch:

• dockerhub-native still has custom_branch_policies=true, protected_branches=false, and exactly one deployment policy: ID 65279581, type tag, pattern native-[0-9]*. The former main policy is absent; no branch policy or second tag policy exists.
• refs/tags/native-3.0.2 is an annotated tag object 687120071d02010022549c817deb5fc7f93077cc, which peels directly to accepted 3.0.2 source commit 0e6fc80a34941098696c53f42289874cf9f98d15.
• The annotated message names the accepted composition (Native: answered queries no longer hold query queue capacity #965, Native describe: a failed run's terminal failure, as PHP reports it #968, Native: offline backup-hold release and read-only inspect for restores (#973) #974, Native: honour an activity's cancellation policy on whole-run delivery #969), schema 8 unchanged, and the reviewed Native release: dispatch from the release tag, and name the version at startup #957/Helm chart 1.0.0: native 3.x mode by default, PHP selectable #963 carry. The tag object is unsigned; this is recorded rather than represented as signature verification. The release workflow's reviewed source/run/attestation gates remain the artifact authority.
• Protected main independently resolves to the same verified merge commit 0e6fc80a….
• No native-release.yml run for native-3.0.2 existed at readback time; the tag push itself did not dispatch publication.

The environment is tag-only and the tag/source binding is exact. Security clears the one reviewed native-release.yml workflow_dispatch from refs/tags/native-3.0.2 with inputs tag=native-3.0.2 and release_commit=0e6fc80a34941098696c53f42289874cf9f98d15. Do not dispatch from main or a different ref/input. Publication and rolling aliases still require exact run qualification and independent public digest/attestation verification.