Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork6.3k
Feat/actions token permissions#36113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Feat/actions token permissions#36113
Conversation
34937e3 to2f29c25CompareReading through issuego-gitea#24635 to understand requirements.Previous PRs were rejected for security reasons.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Adding tables for permission configuration.Schema might need tweaking as I learn more.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Basic CRUD for repo and org permissions.Might refactor some of this later.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
This solves the org/repo boundary issue mentioned ingo-gitea#24554.Starting to see how this all fits together.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Getting the hierarchy right is tricky. Fork PRs need to beabsolutely locked down for security.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Testing fork PR restrictions, org caps, and workflow limits.Should have decent coverage now.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
GET/PUT/DELETE for repo-level settings.Following existing Gitea API patterns.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Also added cross-repo access management.This part took longer than expected.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Three permission modes with individual toggles.UI could use some polish but functional.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
End-to-end testing of the permission configuration flow.Covers most important scenarios.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
- Register Actions permissions migration asgo-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 importsNote: 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 <balavignesh449@gmail.com>
- 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 verificationSigned-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
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 <balavignesh449@gmail.com>
Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Replace all ctx.APIError(http.StatusInternalServerError, err) callswith ctx.APIErrorInternal(err) to match Gitea's standard errorhandling conventions.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
- 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 duplicationSigned-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
The reqOrgOwnership middleware requires ctx.Org to be populated.Added context.OrgAssignment() to the route group to ensure this.Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
Signed-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
2f29c25 to349a1a7CompareSigned-off-by: SBALAVIGNESH123 <balavignesh449@gmail.com>
dbcdd52 toa7b8046Compare| } | ||
| }); | ||
| }); | ||
| </script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Move this toweb_src/js, we can't allow inline scripts because we aim to run under strict CSP.
…ance- Created web_src/js/features/repo-actions-permissions.ts- Moved JavaScript logic from inline script to TypeScript module- Registered function in index-domready.ts initialization- Removed inline <script> tags from template- Addresses silverwind's CSP compliance request
| PermissionModePermissionMode`xorm:"NOT NULL DEFAULT 0"` | ||
| // Granular permissions (only used in Custom mode) | ||
| ActionsReadbool`xorm:"NOT NULL DEFAULT false"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Can these fields be replaced byunit.Type andperm.AccessMode? Just likeTeamUnit
gitea/models/organization/team_unit.go
Lines 14 to 21 inebf9b4d
| // TeamUnit describes all units of a repository | |
| typeTeamUnitstruct { | |
| IDint64`xorm:"pk autoincr"` | |
| OrgIDint64`xorm:"INDEX"` | |
| TeamIDint64`xorm:"UNIQUE(s)"` | |
| Type unit.Type`xorm:"UNIQUE(s)"` | |
| AccessMode perm.AccessMode | |
| } |
| PackagesWritebool`xorm:"NOT NULL DEFAULT false"` | ||
| PullRequestsReadbool`xorm:"NOT NULL DEFAULT false"` | ||
| PullRequestsWritebool`xorm:"NOT NULL DEFAULT false"` | ||
| MetadataReadbool`xorm:"NOT NULL DEFAULT true"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I don't quite understand the purpose ofMetadataRead, its value always seems to be true.
Zettat123 commentedDec 17, 2025
Could you please fix these CI failures? |
| import{initGlobalComboMarkdownEditor,initGlobalEnterQuickSubmit,initGlobalFormDirtyLeaveConfirm}from'./features/common-form.ts'; | ||
| import{callInitFunctions}from'./modules/init.ts'; | ||
| import{initRepoViewFileTree}from'./features/repo-view-file-tree.ts'; | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Remove this needless reformatting.
| console.log('Write permission enabled - ensure this is intentional'); | ||
| } | ||
| }); | ||
| } |
silverwindDec 18, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
2-space indentation for TS please. It's also configured in.editorconfig like that.
Uh oh!
There was an error while loading.Please reload this page.
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.