feat(github): record reviewed commits and signers, and check them in the four-eyes policy

[AlexKantor87]

Record, on GitHub pull request attestations, the commit each approval was given on, the PR's final commit and who signed each commit, and use them in the four-eyes policy. The policy compared approvals with commit dates and trusted commit author fields, both of which come from the commit itself.

🤖 Generated with Claude Code

[AlexKantor87]

Behaviour changes

• approvers now lists each reviewer's latest review, from people with write access, keeping approvals by user accounts only. Attestations list fewer approvers where outside reviewers, bots or superseded approvals were present. Worth a release note; whether it's a major version is a release decision.
• The four-eyes policy needs a repository param (the workflow passes github.repository), requires a verified signature on every PR commit, and gives no approval to attestations from older CLIs.

Merge order

• The Kosli server must store the new fields before a CLI that sends them is released. That change is deploying separately.
• Until CI installs a release with these fields (KOSLI_CLI_VERSION), the four-eyes result on build trails is red. It runs with --no-assert, so nothing is blocked.

Checked against GitHub

Ran the new query shapes on #1239 (a dependabot PR): the human approval comes back from latestOpinionatedReviews(writersOnly: true) on headRefOid, and GitHub-signed commits name web-flow as signer, which the CLI leaves out.

[claude]

Claude finished @AlexKantor87's task in 2m 24s —— View job

---

Review of PR #1244

• Static analysis (build, vet, mod tidy)
• Read diff
• Review & post feedback

Static checks: go build ./... ✅ · go vet ./... ✅ · go mod tidy leaves go.mod/go.sum unchanged ✅
I couldn't run go test because of tool permissions in this job, so I haven't run the new Rego tests or the internal/github tests.

Issues

1. Rollout order (high) – inline. init_kosli.yml records the pr attestation with the released CLI (vars.KOSLI_CLI_VERSION), but it evaluates the policy from the branch. Until a release that includes this PR is out and the var is bumped, head_sha, commit_sha and the signer fields will be missing. Every trail will then get a non-compliant four-eyes-result, starting with this PR's own merge. To avoid that, release the Go changes before merging the policy, or record the attestation with the CLI built from the branch.
2. Stricter behaviour (doc) – approvals given before an "Update branch" merge stop counting, even when branch protection keeps them. That's correct, but it should be in the PR description and changelog.
3. GitHub-signed commits (question) – inline. For these commits author_username is the only identity. That holds for web-UI commits; it's worth confirming for commits a GitHub App or Action creates through the API, and adding a short comment on why it's safe.

Notes (no change needed)

• latestOpinionatedReviews(writersOnly: true) together with the State == "APPROVED" filter correctly drops approvals that were superseded by "changes requested" and approvals from people without write access. writersOnly checks current access, so re-attesting an old PR after someone loses access will drop their approval. That's acceptable, but good to know.
• Excluding reviews where __typename != "User" also drops reviews from deleted accounts, whose author is null. Before this PR those were recorded with an empty login, so this is fine.
• pr_in_repo splits the URL and expects exactly 7 parts. That works for github.com and GHES (https://host/owner/repo/pull/N), and it is deliberately strict, so a malformed URL fails.

Good work

• It's the right fix: it uses the commit each review was given on and verified signers instead of commit dates and author fields, which the person writing the commit controls.
• signed_by_github is a *bool, so "unsigned" stays distinct from false, which matches the existing Verified/SignatureState handling.
• The Rego test suite is thorough (about 40 cases: backdated pushes, forks, ghost or unknown signers, a signer approving their own commit under another author's name, case-insensitive matching). Running it from go test through tester.Run means it can't quietly stop running.
• The required repository param gets a clear violation message instead of failing silently.

[claude]

Rollout order: init_kosli.yml records the pr attestation with the released CLI (setup-cli-action with vars.KOSLI_CLI_VERSION, line 53–56), but it evaluates this policy from the checked-out branch. Until a release that includes this PR is cut and KOSLI_CLI_VERSION is bumped, pr attestations won't have head_sha, commit_sha, signer_username or signed_by_github. Every trail will then fail, starting with this PR's own merge commit. --no-assert keeps the build green, but a non-compliant four-eyes-result gets recorded for each of those trails.

Two ways to handle it:

• merge the Go changes first, release, bump the var, then merge the policy change; or
• in init_kosli.yml, install the CLI from the branch build for the pr attestation step.

Related, and worth stating in the PR description: approvals given before an "Update branch" merge commit stop counting, because the head moves. That is correct for four-eyes, but it is stricter than branch protection when "dismiss stale approvals" is off, so people may see unexpected failures.

[claude]

Minor/question: for a GitHub-signed commit, signer_username is deliberately left empty (github.go, !g), so author_username is the only identity for it. That holds for web-UI and "Update branch" commits, where GitHub sets the author to the acting user. A GitHub App or Action can also create commits through the API (for example createCommitOnBranch or the REST git-data endpoints), and GitHub signs those too. Do we know whether the author on those can differ from the token's identity? If it can, we'd be trusting a field the writer controls again. Even if it can't, a short comment here saying why the GitHub-signed case is safe would help.