[CVSS 5.3 Medium](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) -- The `/repos/{owner}/{repo}/issues/{index}/dependencies` APIs allow a user to link an issue in one repository as "depending upon" an issue in another repository. Forgejo's implementation had an incorrect permission check which would verify only that the user had write permissions on the issue being modified, and not on the issue it was linking to. Due to the incorrect permission check, it was possible to view limited information (the existence of, and title of) an issue in a private repository that the user does not have access to view. The permission check has been corrected to take into account visibility of the remote repository.
[CVSS 5.3 Medium](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) -- Fetching information about a release via the `/repos/{owner}/{repo}/releases/tag/{tag}` API endpoint did not check whether the release was a draft, allowing accessing to information about a draft release to users who could predict an upcoming release tag but didn't have access to view it. The missing check has been added, returning a 404 response when the release is not published.
[CVSS 6.3 Medium](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) -- Forgejo's web interface allows deleting tags on a git repository through a form post. The endpoint for this form post had misconfigured middleware handlers which enforce security rights, allowing an anonymous user, or a logged-in user without the correct permissions, to delete tags on repositories that they did not own by injecting arbitrary internal tag identifiers into the form. The middleware handler configuration has been corrected.
[CVSS 2.1 Low](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) -- When the head branch of a pull request matches a branch protection rule, the head branch should be able to be merged or rebased only according to the "Push" rules defined in the protection rule. An implementation error checked those branch protection rules in the context of the base repository rather than the head repository, allowing users with write access to the base repository to be considered able to push to the branch, bypassing the "Enable push" option's expected security control.
[CVSS 2.1 Low](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) -- An issue owner can manipulate form inputs to delete the content history of comments they did not create, as long as those comments are on issues that they own. Although comment content is not affected, the history of edits on the comment can be trimmed. The validation in the form handler was corrected.
[CVSS 5.1 Medium](https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) -- When a repository is configured with tag protection rules, it should not be possible for a user that is outside the whitelisted users or teams from modifying the protected tags. An incorrect parameter being passed to a security verification method allowed a user with write access to the repo to delete tags even if they were protected, as long as the tag was originally created by a user who is still authorized by the protection rules.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Security bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 0 --><!--description Zml4KGFwaSk6IGZpeCBkZXBlbmRlbmN5IHJlcG8gcGVybXMgaW4gQ3JlYXRlL1JlbW92ZUlzc3VlRGVwZW5kZW5jeQ==-->fix(api): fix dependency repo perms in Create/RemoveIssueDependency<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 1 --><!--description Zml4KGFwaSk6IGRyYWZ0IHJlbGVhc2VzIGNvdWxkIGJlIHJlYWQgYmVmb3JlIGJlaW5nIHB1Ymxpc2hlZA==-->fix(api): draft releases could be read before being published<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 2 --><!--description bWlzY29uZmlndXJlZCBzZWN1cml0eSBjaGVja3Mgb24gdGFnIGRlbGV0ZSB3ZWIgZm9ybQ==-->misconfigured security checks on tag delete web form<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 3 --><!--description aW5jb3JyZWN0IGxvZ2ljIGluICJVcGRhdGUgUFIiIGRpZCBub3QgZW5mb3JjZSBoZWFkIGJyYW5jaCBwcm90ZWN0aW9uIHJ1bGVzIGNvcnJlY3RseQ==-->incorrect logic in "Update PR" did not enforce head branch protection rules correctly<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 4 --><!--description aXNzdWUgb3duZXIgY2FuIGRlbGV0ZSBhbm90aGVyIHVzZXIncyBjb21tZW50J3MgZWRpdCBoaXN0b3J5IG9uIHNhbWUgaXNzdWU=-->issue owner can delete another user's comment's edit history on same issue<!--description-->
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10037): <!--number 10037 --><!--line 5 --><!--description dGFnIHByb3RlY3Rpb24gcnVsZXMgY2FuIGJlIGJ5cGFzc2VkIGR1cmluZyB0YWcgZGVsZXRlIG9wZXJhdGlvbg==-->tag protection rules can be bypassed during tag delete operation<!--description-->
<!--end release-notes-assistant-->
Co-authored-by: Joshua Rogers <MegaManSec@users.noreply.github.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10037
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Adds new a function, `AcceptsGithubResponse`, to the API router context struct to check if the requests accepts a Github response. Although Forgejo API will never be compatible with the Github API, historically Forgejo's API has been designed to follow that of Github closely and we know that a lot of tooling that uses the Github API can be used against the Forgejo API with little to no problem.
As a meet in the middle solution, this function can be used to respond with a more appropriate response that follows the Github API. This allows Forgejo to avoid breaking compatibility with existing users of the API and allows the API to be oh so slightly more compatible with that of Github for API clients that expect a Github response.
Because the `upload_url` field was added purely to match the Github API (forgejo/forgejo#580), it is fair to actually make it compatible with how the Github API intended it to be and that is by adding `{?name,label}` which is used by Github's Oktokit.
Only add `{?name,label}` when Forgejo knows the request accepts a Github response. This avoids breaking the API compatibility with non-Github API clients.
ResolvesCodeberg/Community#2132
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9285
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- When the issue unit is disabled for a repository, don't allow issue related APIs.
- Added integration tests.
- Resolves#8408
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8829
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: zokki <zokki.softwareschmiede@gmail.com>
Co-committed-by: zokki <zokki.softwareschmiede@gmail.com>
Currently, if you try to add an "external" link to a release in Forgejo,
the validation code checks for basic URL soundness and then specifically
checks that the URL is not an API URL.
In some cases, it may make sense to link to instance API URLs (like when
you want to create a release that links to several different repos'
packages). Relax this check so it only validates basic URL soundness.
Refs: https://codeberg.org/forgejo/forgejo/issues/7598
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org).
### Tests
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)).
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
See: https://codeberg.org/forgejo/docs/pulls/1161
### Release notes
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/7644): <!--number 7644 --><!--line 0 --><!--description YWxsb3cgaW5zdGFuY2UgQVBJIFVSTHMgaW4gcmVsZWFzZSBhc3NldHM=-->allow instance API URLs in release assets<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7644
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Malte Jürgens <maltejur@noreply.codeberg.org>
Co-authored-by: John Moon <john.moon@vts-i.com>
Co-committed-by: John Moon <john.moon@vts-i.com>
A 500 status code was thrown when passing a non-existent target to the
create release API. This snapshot handles this error and instead throws
a 404 status code.
Discovered while working on #31840.
(cherry picked from commit f05d9c98c4cb95e3a8a71bf3e2f8f4529e09f96f)
Fixes#30959
Adds an API test for protected tags.
Fix existing tag in combination with fixtures.
(cherry picked from commit b1d8f13bd0ecd9c576ebf2ecbd9c7dbeb3f5254f)
Resolve all cases for `unused parameter` and `unnecessary type
arguments`
Related: #30729
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit e80466f7349164ce4cf3c07bdac30d736d20f035)
Conflicts:
modules/markup/markdown/transform_codespan.go
modules/setting/incoming_email.go
routers/api/v1/admin/user_badge.go
routers/private/hook_pre_receive.go
tests/integration/repo_search_test.go
resolved by discarding the change, this is linting only and
for the sake of avoiding future conflicts
This adds a new options to releases to hide the links to the automatically generated archives. This is useful, when the automatically generated Archives are broken e.g. because of Submodules.
Note:
This juts hides the Archives from the UI. Users can still download 5the Archive if they know t correct URL.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3139
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: JakobDev <jakobdev@gmx.de>
Co-committed-by: JakobDev <jakobdev@gmx.de>
## Purpose
This is a refactor toward building an abstraction over managing git
repositories.
Afterwards, it does not matter anymore if they are stored on the local
disk or somewhere remote.
## What this PR changes
We used `git.OpenRepository` everywhere previously.
Now, we should split them into two distinct functions:
Firstly, there are temporary repositories which do not change:
```go
git.OpenRepository(ctx, diskPath)
```
Gitea managed repositories having a record in the database in the
`repository` table are moved into the new package `gitrepo`:
```go
gitrepo.OpenRepository(ctx, repo_model.Repo)
```
Why is `repo_model.Repository` the second parameter instead of file
path?
Because then we can easily adapt our repository storage strategy.
The repositories can be stored locally, however, they could just as well
be stored on a remote server.
## Further changes in other PRs
- A Git Command wrapper on package `gitrepo` could be created. i.e.
`NewCommand(ctx, repo_model.Repository, commands...)`. `git.RunOpts{Dir:
repo.RepoPath()}`, the directory should be empty before invoking this
method and it can be filled in the function only. #28940
- Remove the `RepoPath()`/`WikiPath()` functions to reduce the
possibility of mistakes.
---------
Co-authored-by: delvh <dev.lh@web.de>
- Resolves https://codeberg.org/forgejo/forgejo/issues/580
- Return a `upload_field` to any release API response, which points to
the API URL for uploading new assets.
- Adds unit test.
- Adds integration testing to verify URL is returned correctly and that
upload endpoint actually works
---------
Co-authored-by: Gusted <postmaster@gusted.xyz>
## Changes
- Adds the following high level access scopes, each with `read` and
`write` levels:
- `activitypub`
- `admin` (hidden if user is not a site admin)
- `misc`
- `notification`
- `organization`
- `package`
- `issue`
- `repository`
- `user`
- Adds new middleware function `tokenRequiresScopes()` in addition to
`reqToken()`
- `tokenRequiresScopes()` is used for each high-level api section
- _if_ a scoped token is present, checks that the required scope is
included based on the section and HTTP method
- `reqToken()` is used for individual routes
- checks that required authentication is present (but does not check
scope levels as this will already have been handled by
`tokenRequiresScopes()`
- Adds migration to convert old scoped access tokens to the new set of
scopes
- Updates the user interface for scope selection
### User interface example
<img width="903" alt="Screen Shot 2023-05-31 at 1 56 55 PM"
src="https://github.com/go-gitea/gitea/assets/23248839/654766ec-2143-4f59-9037-3b51600e32f3">
<img width="917" alt="Screen Shot 2023-05-31 at 1 56 43 PM"
src="https://github.com/go-gitea/gitea/assets/23248839/1ad64081-012c-4a73-b393-66b30352654c">
## tokenRequiresScopes Design Decision
- `tokenRequiresScopes()` was added to more reliably cover api routes.
For an incoming request, this function uses the given scope category
(say `AccessTokenScopeCategoryOrganization`) and the HTTP method (say
`DELETE`) and verifies that any scoped tokens in use include
`delete:organization`.
- `reqToken()` is used to enforce auth for individual routes that
require it. If a scoped token is not present for a request,
`tokenRequiresScopes()` will not return an error
## TODO
- [x] Alphabetize scope categories
- [x] Change 'public repos only' to a radio button (private vs public).
Also expand this to organizations
- [X] Disable token creation if no scopes selected. Alternatively, show
warning
- [x] `reqToken()` is missing from many `POST/DELETE` routes in the api.
`tokenRequiresScopes()` only checks that a given token has the correct
scope, `reqToken()` must be used to check that a token (or some other
auth) is present.
- _This should be addressed in this PR_
- [x] The migration should be reviewed very carefully in order to
minimize access changes to existing user tokens.
- _This should be addressed in this PR_
- [x] Link to api to swagger documentation, clarify what
read/write/delete levels correspond to
- [x] Review cases where more than one scope is needed as this directly
deviates from the api definition.
- _This should be addressed in this PR_
- For example:
```go
m.Group("/users/{username}/orgs", func() {
m.Get("", reqToken(), org.ListUserOrgs)
m.Get("/{org}/permissions", reqToken(), org.GetUserOrgsPermissions)
}, tokenRequiresScopes(auth_model.AccessTokenScopeCategoryUser,
auth_model.AccessTokenScopeCategoryOrganization),
context_service.UserAssignmentAPI())
```
## Future improvements
- [ ] Add required scopes to swagger documentation
- [ ] Redesign `reqToken()` to be opt-out rather than opt-in
- [ ] Subdivide scopes like `repository`
- [ ] Once a token is created, if it has no scopes, we should display
text instead of an empty bullet point
- [ ] If the 'public repos only' option is selected, should read
categories be selected by default
Closes#24501Closes#24799
Co-authored-by: Jonathan Tran <jon@allspice.io>
Co-authored-by: Kyle D <kdumontnu@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
This PR adds the support for scopes of access tokens, mimicking the
design of GitHub OAuth scopes.
The changes of the core logic are in `models/auth` that `AccessToken`
struct will have a `Scope` field. The normalized (no duplication of
scope), comma-separated scope string will be stored in `access_token`
table in the database.
In `services/auth`, the scope will be stored in context, which will be
used by `reqToken` middleware in API calls. Only OAuth2 tokens will have
granular token scopes, while others like BasicAuth will default to scope
`all`.
A large amount of work happens in `routers/api/v1/api.go` and the
corresponding `tests/integration` tests, that is adding necessary scopes
to each of the API calls as they fit.
- [x] Add `Scope` field to `AccessToken`
- [x] Add access control to all API endpoints
- [x] Update frontend & backend for when creating tokens
- [x] Add a database migration for `scope` column (enable 'all' access
to past tokens)
I'm aiming to complete it before Gitea 1.19 release.
Fixes#4300
Change all license headers to comply with REUSE specification.
Fix#16132
Co-authored-by: flynnnnnnnnnn <flynnnnnnnnnn@github>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
