Skip to content

ref(git): Fold GrantV1 and GrantV2 into one Grant with optional rules - #189

Closed
vaind wants to merge 9 commits into
mainfrom
ivan/git-grant-single
Closed

vaind wants to merge 9 commits into
mainfrom
ivan/git-grant-single

Conversation

@vaind

@vaind vaind commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

No description provided.

vaind and others added 9 commits November 9, 2026 17:53
A sandbox holds one grant at a time, and a grant names one operation and a
list of repositories, so a pod that both fetches and pushes can't get both,
and nothing limits either to branches.

GrantV2 holds a list of rules, each a repository, an operation and the
branches it may touch. A fetch rule sets any_object instead of branches to
read everything, so a rule that leaves its branches out is refused rather
than read as a full read. Grant, version 1, still signs and verifies, and
its pushes are relayed unread, so signers can switch once verifiers read
both.

GitServer reads a push's ref updates before the pack and refuses the whole
push if one updates an unlisted branch, deletes a branch, updates another
ref or carries push options. git reads the answer only after sending the
whole push, so the server reads the pack to the end, then answers with a
status report that git shows as rejected refs with their reasons. Fetch
rules that list branches are refused until the server can keep a fetch to
them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…anches

Seer can let the pod push in two ways: add each branch to the grant before
the pod pushes it, or let the pod start branches under a prefix and add
each one once it exists. The second needs a rule that matches names it
doesn't know yet and can't move a branch someone else made.

A push rule now sets branch_patterns, full-match regular expressions, in
place of branches, and create_only allows only updates whose old id is all
zeros, which the provider refuses for a branch that exists. Several rules
may name one repository and operation, and an update passes if any allows
it, so a create_only pattern sits next to the branch the pod already made.

Signing a version 1 Grant now warns, and the class is marked deprecated
for type checkers. Verifying one stays quiet.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Grant is deprecated, so the README, which reads as the module's docs,
points new callers at GrantV2 alone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…uietly

git_malformed_request_body matches rpc_malformed_request_body and says
which part of the request was wrong. Signing a version 1 Grant no longer
warns at runtime, since the class's deprecation already shows in type
checkers and IDEs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Next to GrantV2 the version 1 grant reads clearer with its version in the
name. Grant stays an alias of it, so code that imports Grant keeps working.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A push that updates a ref no rule allows is the grant not allowing that
operation, so it reuses the existing code, and its detail names the ref
and the reason.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
It only ever held GrantV1's version, which the class's own field already
holds, so GrantV1 stops reading it and the constant goes when GrantV1 does.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Grant stays the one public class, so sign_grant, verify_grant and authorize_request keep their released signatures and the name never has to go. A grant sets rules, or the deprecated version 1 operation and repositories, and its version claim follows from which.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@vaind
vaind changed the base branch from ivan/git-grant-rules to main November 9, 2026 18:34
@vaind

vaind commented Nov 9, 2026

Copy link
Copy Markdown
Contributor Author

Going with GrantV1 and GrantV2 in #188.

@vaind vaind closed this Nov 9, 2026
@vaind
vaind deleted the ivan/git-grant-single branch November 9, 2026 18:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant