9384f0bc0a
Replace the tea-based write + boundary/author read-back with a direct Gitea
REST POST that returns the created record's id, and verify that exact record.
BLOCKER 2 (credential ordering): resolve the acting identity, the write token,
and the read-back token from the SAME effective login. A --login override now
selects the credential used for the POST, GET /user, and the GET-by-id
read-back, so an overridden write is verified against the identity that
performed it -- not the host default. Login-name resolution is best-effort and
non-fatal (the override always wins; otherwise fall back to the host
credential), so exotic/ported hosts still resolve a token.
BLOCKER 1+3 (attribution + tautological tests): the write is now
POST /issues/{n}/comments or POST /pulls/{n}/reviews (event + body + commit_id
== PR head), parsing the provider-returned created id. Verification GETs that
exact id and checks author == acting identity and body (comments) or state +
commit_id (reviews). Keying on the created id closes the concurrency window:
a no-op create yields no id and fails closed with no list-scan fallback, and a
concurrent same-identity record has a different id. The review body travels in
the review submit, removing the separate detached comment.
Tests: the curl stub now models a real server with persistent on-disk
review/comment state -- a POST actually creates+persists a record and returns
its id, and the read-back reads that same state (no fabricated record for the
wrapper to find). Adds same-identity no-op-concurrent and author-mismatch
fail-closed cases for both comments and reviews, and >page-1 pagination
coverage for both. README "Durable review provenance" refreshed for the REST
mechanism.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
5.1 KiB
Git provider wrappers
These scripts provide host-aware GitHub and Gitea issue, pull-request, milestone, and CI operations.
Durable review provenance
A successful provider write command—or a wrapper message based only on that command's exit code—is not durable review provenance. Review comments, approvals, and change requests count as durable provenance only after the wrapper reads the created provider record back and verifies that it was created by this write.
The write is a direct Gitea REST POST that returns the created record's id. Neither wrapper writes through tea — tea 0.11.1 can silently no-op while exiting 0 and cannot emit the id of a record it creates, so its exit code is worthless as proof of a durable write (#865). Instead:
- Comments (
issue-comment.sh, and thecommentaction ofpr-review.sh)POST /api/v1/repos/{owner}/{repo}/issues/{index}/comments, requiring a201and parsing the created comment'sidfrom the response body. - Reviews (
approve/request-changes)POST /api/v1/repos/{owner}/{repo}/pulls/{index}/reviewswith theevent(APPROVED/REQUEST_CHANGES), the reviewbody, andcommit_idpinned to the PR's current head, then parse the created review'sid. The review body travels in the review submit itself — there is no separate detached comment to reconcile (a GiteaREQUEST_CHANGESreview requires a non-empty body, which the submit carries).
Verification keys on that exact provider-returned id. The wrapper then GETs that one record directly — GET /issues/comments/{id} or GET /pulls/{n}/reviews/{id} — and requires that its id equals the created id, its author login equals the acting identity (resolved via GET /api/v1/user for the token in use), and, for comments, its body exactly matches what was submitted, or, for reviews, its state matches the requested action and its reviewed commit_id equals the PR head. The write, the /user identity lookup, and the read-back all use the same credential — the effective login's token, or the host credential when no login is named — so the write is verified against the identity that actually performed it.
This closes the concurrency window rather than documenting it. Because verification keys on the id the create returned, a no-op create yields no id and fails closed with no list-scan fallback, and a concurrent record — even one written by the same identity with an identical body/state — has a different id and cannot be mistaken for this write. There is no residual same-identity window: the earlier boundary-and-author heuristic (accept any id > pre-write-max with a matching author) is replaced entirely by exact-id attribution.
Full pagination. After the exact-id read-back, each wrapper also confirms the created id is enumerable in the record list, walking every page (?limit=&page=1,2,… until a short/empty page) so a record that lands beyond the first page is still found regardless of how many comments or reviews already exist.
tea invocation notes (Gitea)
- tea v0.11.1 has no
commentsubcommand undertea prortea issue— thetea pr comment/tea issue commentforms don't error, they silently fall through to a no-op and still exit 0, producing a false-success write (#865). tea's write subcommands (tea comment,tea pr approve/reject) also cannot report the id of the record they create, so their exit code cannot prove a durable write. These wrappers therefore do not write reviews or comments throughteaat all; they use direct Gitea RESTPOSTs that return the created record's id (see "Durable review provenance" above).teais consulted only to enumerate the login list for host→login resolution. - Because the review body is carried in the
POST …/reviewssubmit itself, there is no separate detached review comment, and the historicaltea pr approve/rejecttrailing-positional-argument vs. nonexistent--comment/-commentflag hazard (#835) no longer applies to these wrappers — no review comment is ever passed totea.
--login override
Both pr-review.sh and issue-comment.sh accept an optional --login <name> flag that overrides the automatically detected Gitea login for that single invocation. The override selects which credential the REST write, the /user identity lookup, and the read-back all use — its token is resolved from the tea config for that login name (get_gitea_token_for_login), falling back to the repo host's credential when no login is named. Resolving the acting identity and the read-back from the same login that performs the write is essential: a write performed under an overridden login must be verified against that login's identity, not the host default's. Callers who need a different login than the host default should pass --login <reviewer-login>.
As a durable successor to this mechanism, consider giving each reviewer/approver slot its own dedicated Gitea login credential, so that author≠reviewer holds at the credential level rather than relying on wrapper-level --login bookkeeping. This is a recommendation for future hardening, not something implemented by this flag.