## Overview
This PR introduces granular permission controls for Gitea Actions tokens
(`GITEA_TOKEN`), aligning Gitea's security model with GitHub Actions
standards while maintaining compatibility with Gitea's unique repository
unit system.
It addresses the need for finer access control by allowing
administrators and repository owners to define default token
permissions, set maximum permission ceilings, and control
cross-repository access within organizations.
## Key Features
### 1. Granular Token Permissions
- **Standard Keyword Support**: Implements support for the
`permissions:` keyword in workflow and job YAML files (e.g., `contents:
read`, `issues: write`).
- **Permission Modes**:
- **Permissive**: Default write access for most units (backwards
compatible).
- **Restricted**: Default read-only access for `contents` and
`packages`, with no access to other units.
- ~~**Custom**: Allows defining specific default levels for each unit
type (Code, Issues, PRs, Packages, etc.).~~**EDIT removed UI was
confusing**
- **Clamping Logic**: Workflow-defined permissions are automatically
"clamped" by repository or organization-level maximum settings.
Workflows cannot escalate their own permissions beyond these limits.
### 2. Organization & Repository Settings
- **Settings UI**: Added new settings pages at both Organization and
Repository levels to manage Actions token defaults and maximums.
- **Inheritance**: Repositories can be configured to "Follow
organization-level configuration," simplifying management across large
organizations.
- **Cross-Repository Access**: Added a policy to control whether Actions
workflows can access other repositories or packages within the same
organization. This can be set to "None," "All," or restricted to a
"Selected" list of repositories.
### 3. Security Hardening
- **Fork Pull Request Protection**: Tokens for workflows triggered by
pull requests from forks are strictly enforced as read-only, regardless
of repository settings.
- ~~**Package Access**: Actions tokens can now only access packages
explicitly linked to a repository, with cross-repo access governed by
the organization's security policy.~~ **EDIT removed
https://github.com/go-gitea/gitea/pull/36173#issuecomment-3873675346**
- **Git Hook Integration**: Propagates Actions Task IDs to git hooks to
ensure that pushes performed by Actions tokens respect the specific
permissions granted at runtime.
### 4. Technical Implementation
- **Permission Persistence**: Parsed permissions are calculated at job
creation and stored in the `action_run_job` table. This ensures the
token's authority is deterministic throughout the job's lifecycle.
- **Parsing Priority**: Implemented a priority system in the YAML parser
where the broad `contents` scope is applied first, allowing granular
scopes like `code` or `releases` to override it for precise control.
- **Re-runs**: Permissions are re-evaluated during a job re-run to
incorporate any changes made to repository settings in the interim.
### How to Test
1. **Unit Tests**: Run `go test ./services/actions/...` and `go test
./models/repo/...` to verify parsing logic and permission clamping.
2. **Integration Tests**: Comprehensive tests have been added to
`tests/integration/actions_job_token_test.go` covering:
- Permissive vs. Restricted mode behavior.
- YAML `permissions:` keyword evaluation.
- Organization cross-repo access policies.
- Resource access (Git, API, and Packages) under various permission
configs.
3. **Manual Verification**:
- Navigate to **Site/Org/Repo Settings -> Actions -> General**.
- Change "Default Token Permissions" and verify that newly triggered
workflows reflect these changes in their `GITEA_TOKEN` capabilities.
- Attempt a cross-repo API call from an Action and verify the Org policy
is enforced.
## Documentation
Added a PR in gitea's docs for this :
https://gitea.com/gitea/docs/pulls/318
## UI:
<img width="1366" height="619" alt="Screenshot 2026-01-24 174112"
src="https://github.com/user-attachments/assets/bfa29c9a-4ea5-4346-9410-16d491ef3d44"
/>
<img width="1360" height="621" alt="Screenshot 2026-01-24 174048"
src="https://github.com/user-attachments/assets/d5ec46c8-9a13-4874-a6a4-fb379936cef5"
/>
/fixes #24635
/claim #24635
---------
Signed-off-by: Excellencedev <ademiluyisuccessandexcellence@gmail.com>
Signed-off-by: ChristopherHX <christopher.homberger@web.de>
Signed-off-by: silverwind <me@silverwind.io>
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: ChristopherHX <christopher.homberger@web.de>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Zettat123 <zettat123@gmail.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
The design of DefaultShowFullName has some problems, which make the UI
inconsistent, see the new comment in code
This PR does a clean up for various legacy problems, and clarify some
"user name display" behaviors.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
After many years, "activitypub" is still "in progress" and no real
progress for end users. So it is not mature.
Temporarily mark the endpoints as "501 not implemented",
and wait until the whole design is stable and usable.
I was testing typos-cli and fixed some misspelled wording here.
All changes are internal — no public API fields, database columns,
locale keys, or migration names are affected.
* Fix#35685
* Fix#35627
* Fix#31112
Introduce "fipped" config value type, remove unused setting variables.
Make DisableGravatar=true by defult, remove useless config options from
the "Install" page.
The legacy config options are still kept because they are still the
fallback values for the system config options.
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Fixes: https://github.com/go-gitea/gitea/issues/36152
Enable the `nilnil` linter while adding `//nolint` comments to existing
violations. This will ensure no new issues enter the code base while we
can fix existing issues gradually.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The default configuration of `failure-only` added in
https://github.com/go-gitea/gitea/pull/34982 included sending mails for
cancelled runs which is not what one would expect from a option named
like that because a cancelled run is not a failure.
This change makes it omit mails for cancelled runs:
| Run Status | `failure-only` before | `failure-only` after |
|------------|-----------------------|----------------------|
| Success | no | no |
| Failure | mail | mail |
| Cancelled | mail | no |
The first commit in this PR is the fix, and there are a few more
refactor commits afterwards.
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This implements id based hidden emails in format of
`user+id@NoReplyAddress`
resolves: https://github.com/go-gitea/gitea/issues/33471
---
The change is not breaking however it is recommended for users to move
to this newer type of no reply address
---------
Co-authored-by: Lauris B <lauris@nix.lv>
https://github.com/golangci/golangci-lint/releases/tag/v2.6.0
- `modernize` linter is enabled, this is the same as `gopls modernize`
- ~~`perfsprint` linter is disabled because it conflicts with
`modernize` (maybe there is a middle ground)~~
- gocritic `deprecatedComment` is disabled as it conflicts with
`go-swagger`
* use a single function to do Action Tokens Permission checks
* allows easier customization
* add basic tests
* lfs file locks should work now
---------
Signed-off-by: ChristopherHX <christopher.homberger@web.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR adds a feature to direct users to appropriate pages after system
installation:
- If no admin credentials were provided during installation, redirect to
the registration page with a prominent notice about creating the first
administrative account
- If admin credentials were already set, redirect directly to the login
page
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This fixes 3 issues I encountered when debugging problems with our LDAP sync:
1. The comparison of the hashed image data in `IsUploadAvatarChanged` is
wrong. It seems to be from before avatar hashing was changed and unified
in #22289. This results in the function always returning `true` for any
avatars, even if they weren't changed.
2. Even if there's no avatar to upload (i.e. no avatar available for the
LDAP entry), the upload function would still be called for every single
user, only to then fail, because the data isn't valid. This is
unnecessary.
3. Another small issue is that the comparison function (and thus hashing
of data) is called for every user, even if there is no avatar attribute
configured at all for the LDAP source. Thus, I switched the condition
nesting, so that no cycles are wasted when avatar sync isn't configured
in the first place.
I also added a trace log for when there is actually a new avatar being
uploaded for an existing user, which is now only shown when that is
actually the case.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR changes the `opts` argument in `SearchUsers()` to be passed by
value instead of by pointer, as its mutations do not escape the function
scope and are not used elsewhere. This simplifies reasoning about the
function and avoids unnecessary pointer usage.
This insight emerged during an initial attempt to refactor
`RenderUserSearch()`, which currently intermixes multiple concerns.
Co-authored-by: Philip Peterson <philip-peterson@users.noreply.github.com>
This PR adds the label _state_ to the metric _gitea_users_. With the
change, _gitea_users_ would be reported like this:
```
...
# HELP gitea_users Number of Users
# TYPE gitea_users gauge
gitea_users{state="active"} 20
gitea_users{state="inactive"} 10
...
```
The metrics above would be from a Gitea instance with 30 user accounts.
20 of the accounts are active and 10 of the accounts are not active.
Resolve#34325
When list commits, some of the commits authors are the same at many
situations. But current logic will always fetch the same GPG keys from
database. This PR will cache the GPG keys, emails and users for the
context so that reducing the database queries.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR tries to finally fix the bug mentioned in #30011 and #15504,
where the user repo limit is checked when creating a repo in an
organization.
Fix#30011
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: TheFox0x7 <thefox0x7@gmail.com>
1. Ignore empty inputs in `UnmarshalHandleDoubleEncode`
2. Ignore non-existing `stateEvent.User` in gitlab migration
3. Enable `release` and `wiki` units when they are selected in migration
4. Sanitize repo name for migration and new repo
Resolve#29328
This pull request introduces a file tree on the left side when reviewing
files of a repository.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Replace all contexts in tests with go1.24 t.Context()
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
When listing commits, Gitea attempts to retrieve the actual user based
on the commit email. Querying users one by one from the database is
inefficient. This PR optimizes the process by batch querying users by
email, reducing the number of database queries.
