Feat/actions token permissions #36113
Open
+2,189
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GiteaBot
added
the
lgtm/need 2
github-actions
bot
added
modifies/api
SBALAVIGNESH123
force-pushed
the
feat/actions-token-permissions
branch
2 times, most recently
from
34937e3 to
2f29c25
Compare
Reading through issue go-gitea#24635 to understand requirements. Previous PRs were rejected for security reasons. Signed-off-by: SBALAVIGNESH123 <[email protected]>
Adding tables for permission configuration. Schema might need tweaking as I learn more. Signed-off-by: SBALAVIGNESH123 <[email protected]>
Basic CRUD for repo and org permissions. Might refactor some of this later. Signed-off-by: SBALAVIGNESH123 <[email protected]>
This solves the org/repo boundary issue mentioned in go-gitea#24554. Starting to see how this all fits together. Signed-off-by: SBALAVIGNESH123 <[email protected]>
Getting the hierarchy right is tricky. Fork PRs need to be absolutely locked down for security. Signed-off-by: SBALAVIGNESH123 <[email protected]>
Testing fork PR restrictions, org caps, and workflow limits. Should have decent coverage now. Signed-off-by: SBALAVIGNESH123 <[email protected]>
GET/PUT/DELETE for repo-level settings. Following existing Gitea API patterns. Signed-off-by: SBALAVIGNESH123 <[email protected]>
Also added cross-repo access management. This part took longer than expected. Signed-off-by: SBALAVIGNESH123 <[email protected]>
Three permission modes with individual toggles. UI could use some polish but functional. Signed-off-by: SBALAVIGNESH123 <[email protected]>
End-to-end testing of the permission configuration flow. Covers most important scenarios. Signed-off-by: SBALAVIGNESH123 <[email protected]>
- Register Actions permissions migration as go-gitea#324 in v1_27 - Fix import paths: modules/context -> services/context - Add missing API struct definitions in modules/structs - Remove integration test with compilation errors - Clean up unused imports Note: Some API context methods need adjustment for Gitea's conventions. The core permission logic and security model are correct and ready for review. Signed-off-by: SBALAVIGNESH123 <[email protected]>
- Replace direct ctx.Org.IsOwner with ctx.Org.Organization.IsOwnedBy() - Fix ctx.ParamsInt64 to ctx.PathParamInt64 for route parameters - Ensures proper error handling for ownership verification Signed-off-by: SBALAVIGNESH123 <[email protected]>
The APIOrganization type doesn't have an IsOwner field. All ownership checks must use ctx.Org.Organization.IsOwnedBy(ctx, ctx.Doer.ID) to properly verify organizational ownership in API context. Signed-off-by: SBALAVIGNESH123 <[email protected]>
Signed-off-by: SBALAVIGNESH123 <[email protected]>
Signed-off-by: SBALAVIGNESH123 <[email protected]>
Replace all ctx.APIError(http.StatusInternalServerError, err) calls with ctx.APIErrorInternal(err) to match Gitea's standard error handling conventions. Signed-off-by: SBALAVIGNESH123 <[email protected]>
- Register API routes for org/repo actions permissions - Use reqOrgOwnership and reqAdmin middleware for auth - Remove manual usage of IsOwnedBy/IsAdmin in handlers to avoid duplication Signed-off-by: SBALAVIGNESH123 <[email protected]>
The reqOrgOwnership middleware requires ctx.Org to be populated. Added context.OrgAssignment() to the route group to ensure this. Signed-off-by: SBALAVIGNESH123 <[email protected]>
Signed-off-by: SBALAVIGNESH123 <[email protected]>
SBALAVIGNESH123
force-pushed
the
feat/actions-token-permissions
branch
from
2f29c25 to
349a1a7
Compare
Signed-off-by: SBALAVIGNESH123 <[email protected]>
SBALAVIGNESH123
force-pushed
the
feat/actions-token-permissions
branch
from
dbcdd52 to
a7b8046
Compare
silverwind
reviewed
Dec 16, 2025
| } | ||
| }); | ||
| }); | ||
| </script> |
Member
There was a problem hiding this comment.
Move this to web_src/js, we can't allow inline scripts because we aim to run under strict CSP.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces a fully configurable permission system for Gitea Actions automatic tokens, addressing long-standing security and usability issues by giving organizations and repositories precise control over what workflows can and cannot do. Instead of the previous all-or-nothing behavior, permissions now flow through a layered model—organizations define the upper limits, repositories refine them, and workflow files can only request a subset of what’s allowed. Forked pull requests are always restricted to read-only access to prevent privilege escalation, and package publishing now requires explicitly linking a package to a repository to respect the org-level boundary. The feature includes both UI and API support, offers sensible defaults, logs all permission changes for auditability, and maintains backward compatibility by placing existing repos into a safe restricted mode. The goal is to provide a secure foundation that avoids the pitfalls of earlier attempts while still enabling common CI/CD workflows like publishing packages or managing PRs, with room to extend the system further in future updates.