mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2026-07-18 15:37:48 +00:00
2,238 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Robert Wolff
|
44b93ff7cc |
fix: do not migrate confidential issues and internal notes from Gitlab (#12735)
A dedicated test repository was added at https://gitlab.com/forgejo/test_repo-confidential with one "confidential issue" and two "internal notes". Closes: #12688 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12735 Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org> Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Gusted
|
6c85dffb78 |
fix: load repo language for converting to api struct (#12737)
Load the primary language of the repository when it's converted to a API struct. This is simpler than adding `LoadAttributes` to a lot of places. Resolves forgejo/forgejo#12729 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12737 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Gusted
|
d25f7ae70d |
feat: show progress of issues and PRs migrations (#12738)
These are by the far the longest time spent on during a migration. Indicate the progress of how many issues and PRs were migrated so far. Don't overwhelm the messenger, so they are only updated once a batch is migrated. Which is "slow" enough to see it's not stuck and still doing work. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12738 Reviewed-by: Ellen Εμίλια Άννα Zscheile <fogti@noreply.codeberg.org> Reviewed-by: 0ko <0ko@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
dfdd9b2e2a |
fix: check quota in LFS uploads against the repository owner, not operating user (#12755)
Follow-up to the previously closed #12437; verifies git LFS quotas are checked against the repository owner not the current actor. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - 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 ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. <!--start release-notes-assistant--> ## Release notes <!--URL:https://codeberg.org/forgejo/forgejo--> - Bug fixes - [PR](https://codeberg.org/forgejo/forgejo/pulls/12755): <!--number 12755 --><!--line 0 --><!--description Y2hlY2sgcXVvdGEgaW4gTEZTIHVwbG9hZHMgYWdhaW5zdCB0aGUgcmVwb3NpdG9yeSBvd25lciwgbm90IG9wZXJhdGluZyB1c2Vy-->check quota in LFS uploads against the repository owner, not operating user<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12755 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
nightfurysl2001
|
b58d8e20fd |
feat: Update Microsoft Teams webhook to use AdaptiveCard (#11704)
## 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 for Go changes (can be removed for JavaScript changes) - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [ ] `make pr-go` before pushing ### 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Closes #4517 <!--start release-notes-assistant--> ## Release notes <!--URL:https://codeberg.org/forgejo/forgejo--> - Features - [PR](https://codeberg.org/forgejo/forgejo/pulls/11704): <!--number 11704 --><!--line 0 --><!--description VXBkYXRlIE1pY3Jvc29mdCBUZWFtcyB3ZWJob29rIHRvIHVzZSBBZGFwdGl2ZUNhcmQ=-->Update Microsoft Teams webhook to use AdaptiveCard<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11704 Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org> Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Andreas Ahlenstorf
|
42618ba771 |
fix: update statuses in phases to prevent out of order updates from stalling workflows (#12685)
During workflow expansion, jobs are replaced or added. That means that their execution order does not necessarily match the order of their numeric IDs. For example, job 129 might depend on job 130. Unfortunately, Forgejo doesn't take this possibility into account and always examines and updates jobs by ascending ID. That means that while examining job 129, job 130 has still its old status, and, as a result, Forgejo won't schedule job 129 for execution because it's still waiting for job 130 to complete. This can lead to workflows getting stuck: ``` ...tions/job_emitter.go:48:jobEmitterQueueHandler() [E] checkJobsOfRun failed for RunID = 49: error in tryHandleIncompleteMatrix: jobStatusResolver attempted to tryHandleIncompleteMatrix for a job (id=129) with an incomplete 'needs' job (id=130) ``` This is caused by calculating all status changes recursively in memory before writing them to the database. For example, job A that was completed would unblock job B that depended on it. In that case, Forgejo would simultaneously mark job A as completed and B as waiting. However, that would not work if B had a lower ID than A. That is remedied by writing updates to the database before entering the next recursion. So, continuing the example, job A is marked as completed in the database before the next iteration detects that B is no longer blocked and writes that to the database. Resolves https://codeberg.org/forgejo/forgejo/issues/12641. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes (can be removed for JavaScript changes) - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes (can be removed for Go changes) - 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. *The decision if the pull request will be shown in the release notes is up to the mergers / release team.* The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12685 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
numen
|
3650528262 |
fix: return API URL in the url field for pull requests using the API (#12643)
closes #10451 ### Tests for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [ ] `make pr-go` before pushing ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. <!--start release-notes-assistant--> ## Release notes <!--URL:https://codeberg.org/forgejo/forgejo--> - Bug fixes - [PR](https://codeberg.org/forgejo/forgejo/pulls/12643): <!--number 12643 --><!--line 0 --><!--description cmV0dXJuIEFQSSBVUkwgaW4gdGhlIGB1cmxgIGZpZWxkIGZvciBwdWxsIHJlcXVlc3RzIHVzaW5nIHRoZSBBUEk=-->return API URL in the `url` field for pull requests using the API<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12643 Reviewed-by: Robert Wolff <mahlzahn@posteo.de> Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
hwipl
|
1ea5605eae |
feat: add dynamic group mappings for OIDC (#11656)
Currently, Forgejo supports configuring static group team mappings for
an OIDC authentication source that map OIDC groups to Forgejo
organizations and teams. For example, the following mapping
```json
{"Developer": {"MyForgejoOrganization": ["MyForgejoTeam1", "MyForgejoTeam2"]}}
```
automatically adds a user in the OIDC group `Developer` to the teams
`MyForgejoTeam1` and `MyForgejoTeam2` in organization
`MyForgejoOrganization`.
In order to support more dynamic mappings and to avoid having to update
the mappings for new organizations and teams, add an additional
configuration option that supports mappings with placeholders like in
the following example:
```json
["group-{org}-{team}", "other:{org}/{team}"]
```
In this example, the mappings add a user in OIDC groups
`group-org1-team1`, `group-org2-team2`, and `other:org3/team3` to team
`team1` in organization `org1`, team `team2` in organization `org2`, and
to team `team3` in organization `org3`.
Additionally, this adds a configuration option to dynamically remove
users from organization teams. If enabled, a user is removed from all
teams that are not added via a static or dynamic mapping. Thus, users
are only in teams that are added via such a mapping and no other teams.
Docs: forgejo/docs!1950
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11656
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
|
||
|
Mathieu Fenniak
|
29eddd311b |
chore: upgrade to https://code.forgejo.org/xorm/xorm v1.4.0 (#12639)
Upgrade Forgejo to our forked [xorm v1.4.0](https://code.forgejo.org/xorm/xorm/compare/v1.3.9-forgejo.12...v1.4.0), which is now named `code.forgejo.org/xorm/xorm` to reflect the current expectation that it is a permanent fork. A small number of API changes were made recently in https://code.forgejo.org/xorm/xorm/issues/120 which are accounted for in this PR, in addition to the module rename. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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). ### 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12639 Reviewed-by: Otto <otto@codeberg.org> |
||
|
John Berthels
|
08949c518a |
fix: expose API fields for ssh keys (#12517) (#12625)
The original issue only mentions 'Verified', but 'Updated' was also missing and so is also included. The integration test only covers the initial `false` state. Attempting to cover the flip to true seemed to introduce more problems than benefits (as outlined in `tests/integration/api_keys_test.go`) Manual testing was performed to check that verifying the key in the web ui caused the return value to change from false to true in the API response (using `curl`). ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes (can be removed for JavaScript changes) - 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 ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes (can be removed for Go changes) - 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12625 Reviewed-by: Cyborus <cyborus@disroot.org> Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
cf087a2f12 |
feat: ability to edit authorized integration in web UI (#12601)
Extends the UI introduced in #12558 to have edit capabilities. (not in scope: "Add" for a new Authorized Integration will be the next update to this UI; `create-authorized-integration` CLI is still the only way to create a new record) This PR includes a few refactoring steps. The goal of these steps is to have `services/auth` be a single entrypoint for validating, inserting, or updating an authorized integration. Some logic is moved out of `services/authz` because it is not authorization related, and some is moved out of `services/auth/method` to allow it to be reused during validation without creating a cyclical module dependency. This PR also adds comprehensive validation to the more complex fields in the authorized integration, such as the issuer and claim rules. This validation applies to the `forgejo admin user create-authorized-integration` CLI as well. The visible UI is the same as #12558, but with a "Save" button, and the ability to display errors:  ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [x] 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. - Documentation is on my TODO list and will be completed before release. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12601 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Andreas Ahlenstorf
|
8a1021e2a0 |
feat: mark skipped checks as skipped (#12606)
A separate commit status is introduced for skipped checks. That enables marking them as such in the UI instead of successful, which could be misleading. Resolves https://codeberg.org/forgejo/forgejo/issues/10138. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes (can be removed for JavaScript changes) - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes (can be removed for Go changes) - 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. *The decision if the pull request will be shown in the release notes is up to the mergers / release team.* The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12606 Reviewed-by: Cyborus <cyborus@disroot.org> Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Antonin Delpeuch
|
0a57672544 |
feat: serve downsized versions of avatars (#11242)
Fixes #2325. This introduces a way to download downsized versions of the user and repository avatars: * `/avatars/123abcd` still serves the full-size avatar * `/avatars/123abcd?size=64` serves it at size 64x64 px Those downsized versions are computed on demand when requested for the first time and cached. The caching is done in a storage location configurable in the instance settings, just like the storage locations for the full-sized avatars are. The sizes of the downsized images are restricted to a fixed set of sizes, so that the cache doesn't grow too big. The caching and resizing logic is exposed in a way that could potentially be reused for other types of images (such as user uploads in issue discussions). Luckily, the Go templates already specify in many places which size those avatars should be rendered, even if this information was only used for external avatar providers (such as Gravatar) until now. The range of sizes requested by the HTML templates is rather wide: the table below lists all the sizes I could find, and the corresponding size served by the backend with the logic I implemented. The scaling factor of 2 was already used for requesting resized external avatars, and likely exists to make sure that users with display scaling enabled get a sharper picture. | Size requested in the template | After scaling (x2) | Size of the image served | |---------|---------|---------| | 256 px | 512 px | original (512 px) | | 140 px | 280 px | original (512 px) | | 48 px | 96 px | 128 px | | 40 px | 80 px | 128 px | | 32 px | 64 px | 64 px | | 28 px | 56 px | 64 px | | 24 px | 48 px | 64 px | | 20 px | 40 px | 64 px | Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11242 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Gusted
|
aae19e6c19 |
chore: tidy up uploading migration code (#12577)
- Validate and sanitize topics. - Cap topics at 25 (limit used elsewhere, now unified constant). - Add more details and rephrase common user-facing error messages. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12577 |
||
|
Erwan Leboucher
|
0211c1eace |
feat: persist OAuth2/OIDC sign-in via IdP re-validation (#12321)
The session cookie has no Max-Age, so it is lost when the browser closes. The password flow compensates via a "Remember me" checkbox issuing an LTA cookie; OAuth2/OIDC sign-in had no such UI. Issuing a regular LTA cookie after an OAuth callback would skip the IdP for LOGIN_REMEMBER_DAYS. Instead, this introduces a separate LongTermAuthorizationSSO purpose: the cookie is opt-in via the existing "Remember me" checkbox, and when presented without a session, autoSignIn redirects through the IdP with OIDC prompt=none for silent re-auth. On login_required / interaction_required / consent_required / account_selection_required we transparently fall back to interactive sign-in. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12321 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
2327b3b888 | feat: add 'ui' field to authorized_integration table | ||
|
Mathieu Fenniak
|
6e5dbfa169 |
fix: handle boolean workflow inputs correctly before jobparser evaluates with them (#12539)
Fixes https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/112. Currently boolean `workflow_dispatch` values are being passed as strings during Forgejo's job parsing, causing both true & false to have the same behaviour when evaluated in a condition like this: ``` on: workflow_dispatch: inputs: win32: type: boolean jobs: job1: strategy: matrix: runner: ${{ fromJSON(inputs.win32 == 'true' && '["win32", "win64"]' || '["win64"]') }} steps: # ... ``` ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - 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 ran... - [ ] `make pr-go` before pushing ### 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12539 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
32b8d732b8 |
2026-05-12 security patches (#12493)
- fix: prevent git write to wiki repo from unauthorized user via git HTTP - fix: prevent LFS authorization token from being used for read/write access after user's access is restricted from Forgejo - fix: prevent scoped API access (OAuth tokens, Access tokens) from accessing resources beyond their permitted scope via non-API endpoints (e.g. /user/repo/raw/...) - fix: implementing missing OAuth validation checks, improve protections against race conditions - fix: prevent OAuth redirect URI spoofing via non-ascii case collision - fix: strengthen Actions Artifact V4 signature algorithm against spoofing attacks <!--start release-notes-assistant--> ## Release notes <!--URL:https://codeberg.org/forgejo/forgejo--> - Security bug fixes - [PR](https://codeberg.org/forgejo/forgejo/pulls/12493): <!--number 12493 --><!--line 0 --><!--description MjAyNi0wNS0xMiBzZWN1cml0eSBwYXRjaGVz-->2026-05-12 security patches<!--description--> <!--end release-notes-assistant--> Co-authored-by: Derzsi Dániel <daniel@tohka.us> Co-authored-by: jvoisin <julien.voisin@dustri.org> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12493 |
||
|
Andreas Ahlenstorf
|
753e289da5 |
fix: wipe run artifacts before rerun (#12523)
Forgejo Actions keeps one set of artifacts per workflow run -- those of the latest workflow run. If a particular workflow run is rerun, Forgejo is supposed to remove outdated artifacts. However, it does not do that. As a result, the user is presented a mix of outdated and new artifacts, even within the same archive.
This is remedied by wiping the artifacts before each rerun. The same happens when only one or more jobs are rerun, which also matches the behaviour of GitHub Actions. In the example below, when only rerunning `artifacts-two`, `many-artifacts-one` would disappear and a new version of `many-artifacts-two` would be made available.
Reproducer:
```yaml
on:
push:
jobs:
artifacts-one:
runs-on: ubuntu-latest
steps:
- run: mkdir -p artifacts-one
- run: |
if [[ "${{ github.run_attempt}}" == 1 ]] ; then echo "${{ github.run_attempt}}" > artifacts-one/ONE; fi
echo "${{ github.run_attempt}}" > artifacts-one/TWO
- uses: forgejo/upload-artifact@v4
with:
name: many-artifacts-one
path: artifacts-one/
artifacts-two:
runs-on: ubuntu-latest
steps:
- run: mkdir -p artifacts-two
- run: |
if [[ "${{ github.run_attempt}}" == 1 ]] ; then echo "${{ github.run_attempt}}" > artifacts-two/ONE; fi
echo "${{ github.run_attempt}}" > artifacts-two/TWO
- uses: forgejo/upload-artifact@v4
with:
name: many-artifacts-two
path: artifacts-two/
```
Resolves https://codeberg.org/forgejo/forgejo/issues/12163.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- 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 ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
(can be removed for Go changes)
- 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.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12523
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
|
||
|
Andreas Ahlenstorf
|
03312e4f46 |
feat: make it possible to remove workflow runs (#12478)
Add the ability to remove workflow runs, either using the UI or the HTTP API. Workflow runs can only be removed once a workflow run has completed. For security reasons, only a repository administrator or a token with `write:repository` permissions can remove runs. Resolves https://codeberg.org/forgejo/forgejo/issues/2184. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes (can be removed for JavaScript changes) - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes (can be removed for Go changes) - 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. *The decision if the pull request will be shown in the release notes is up to the mergers / release team.* The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead. <!--start release-notes-assistant--> ## Release notes <!--URL:https://codeberg.org/forgejo/forgejo--> - Features - [PR](https://codeberg.org/forgejo/forgejo/pulls/12478): <!--number 12478 --><!--line 0 --><!--description bWFrZSBpdCBwb3NzaWJsZSB0byByZW1vdmUgd29ya2Zsb3cgcnVucw==-->make it possible to remove workflow runs<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12478 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
e5eb5f8e63 |
feat: allow Authorized Integrations to have multiple values for a claim match (#12482)
Adds new Authorized Integration claim comparison rules for "in a list" and "in a list of globs", which would be required to permit multiple Forgejo Action events to match a JWT (per [design work](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-14510514), [comment](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-14512185)). ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12482 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
famfo
|
169ea1d991 |
fix(activitypub): only return public activities on request (#12382)
The endpoint returning individual activities was missing access control checks, since IDs are sequential, this is not ideal. Fixes #12333 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12382 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
limiting-factor
|
508bb7f2ae |
fix: in actions_service cancelJobsForRun is bugous use killRun instead (#12366)
The cancelJobsForRun function is redundant with the killRun function and has bugs:
- It does not use a transaction and may fail in a non-recoverable way
- It does not update the commit status of the run
- It does not set NeedRemoval to false if needed
Remove the cancelJobsForRun function and use killRun instead (fixing forgejo/forgejo#12386). Both calls are covered by existing tests:
- TestCancelPreviousJobs
- TestCancelPreviousWithConcurrencyGroup
A new integration test TestActionsPullRequestTrustPushCancel is added to verify that the NeedApproval field is set to false whenever a run is cancelled (fixing forgejo/forgejo#12350).
Closes forgejo/forgejo#12350
Closes forgejo/forgejo#12386
---
Reverting the change fails the test at
|
||
|
Andreas Ahlenstorf
|
92863bb103 |
feat: expose run_id in ...actions/runners/jobs endpoint (#12480)
Include `run_id` in the responses emitted by all `...actions/runners/jobs` endpoints. Helps with correlating pending jobs with other jobs and the runs they belong to. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes (can be removed for JavaScript changes) - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes (can be removed for Go changes) - 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. *The decision if the pull request will be shown in the release notes is up to the mergers / release team.* The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12480 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Thanos Apollo
|
3a35c5353e |
feat: expose AGit topic branch in API PR head label (#12352)
For Agit-flow pull requests, `head.label` was explicitly set to an empty string. The head branch name (which contains the Agit topic, e.g. `user2/my-topic`) was already populated from `pr.HeadBranch` but then discarded. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12352 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Reviewed-by: Cyborus <cyborus@disroot.org> |
||
|
Akashdeep Dhar
|
ffd10d37a6 |
fix: ensure moving all commits in a pull request for pagure migration (#12433)
While the changes were conveyed in the pull request in its entirety, the commit history of a pull request having more than one commit was bugged and the log would have shown just the presence of the most recent commit event, having the entire changes contained in a pull request. This is a problem that was mostly noticed in the closed pull request, so it is not as bad as it looks. Even then, if we are migrating closed pull requests, we should do it the right way. We do not want to retain these pull requests for archival purposes if they are not accurate. Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com> Fixes https://forge.fedoraproject.org/forge/forge/issues/556 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12433 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Gusted
|
bf958fa355 |
fix: make package cleanup work again (#12446)
- Regression of forgejo/forgejo!11776 (and forgejo/forgejo!11881) - Scope of the transaction is moved to a per-package cleanup rule basis. This is also a enhancement for scaling (already deployed on Codeberg for a while). - Package cleanup is now run with `RetryTx`, because rebuilding repository files runs `RetryTx` and it could indicate to retry the whole transaction. - Previously it would error and say running `RetryTx` in a transaction was not possible, this is now possible. Nested `RetryTx` is always allowed, matching of which errors to retry is still the responsible of the inner `RetryTx`. Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12446 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Gusted
|
c07ea09050 |
fix: cleanup data before migration retry (#12370)
In the case you hit some API error (Github ratelimit was often a problem) or the instance restarted in the middle of your migration, you would be left with data on the disk and/or database. Upon retrying the migration the migration code would (rightfully) fail because it's trying to migrate stuff that already exists.
This was hit so often on Codeberg it was better to force people to delete and start whole migration process again:
|
||
|
Mathieu Fenniak
|
c1ac671b55 |
feat: reusable workflow outer job is skipped if 'if:' block skips workflow (#12412)
Follow-up to https://code.forgejo.org/forgejo/runner/pulls/1509 -- improves the UX in Forgejo when a reusable workflow is skipped, marking the workflow as skipped rather than succeeded. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12412 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
9b88e77c19 |
feat: expose immutable identifiers in Forgejo Actions JWTs (#12355)
Protect OIDC tokens generated by Forgejo Actions from threats arising when users or repositories are renamed or deleted, freeing their names up for reuse by another user. In this threat environment, relying on the name of users and repositories in validating JWT claims is unsafe because they can change. Adds three new claims to Actions' OIDC tokens: - `actor_id` -- the immutable identifier of the actor who triggered an Action run - `repository_id` -- the immutable identifier of the repository on which the Action is running - `repository_owner_id` -- the immutable identifier of the owner of the repository on which the Action is running Repositories will change their subject (`sub`) OIDC claims to include these immutable identifiers. Existing repositories will not change, in order to maintain compatibility with existing JWT usage. The new format will be applied to new repositories, or can be applied by disabling and enabling the Actions unit. The new format embeds the identifiers: - **Existing repos:** `repo:my-org/my-repo:ref:refs/heads/main` - **New repos:** `repo:my-org-123456/my-repo-456789:ref:refs/heads/main` Fixes #12244. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Documentation - [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - New fields will be added to documentation soon. - [ ] I did not document these changes and I do not expect someone else to do it. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12355 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
steven.guiheux
|
7e205c5718 |
fix: get tag must return the tag signature instead of commit signature (#12351)
## Fix: `GET /api/v1/repos/{owner}/{repo}/git/tags/{sha}` returns empty verification for signed tags
### Problem
When an annotated tag is signed (GPG or SSH) but the underlying commit is **not** signed, the API endpoint `GET /repos/{owner}/{repo}/git/tags/{sha}` returns an empty `verification.signature` field.
This is because `ToAnnotatedTag` was calling `ToVerification(ctx, c)` with the **commit** object, which checks the commit's signature — not the tag's own signature. Since the commit is unsigned, the API returns `signature: ""` and `verified: false`.
This causes issues for tools that rely on the tag signature from the API to validate that a tag push event is from a trusted source.
### Fix
`ToAnnotatedTag` now checks if the tag has its own signature (`t.Signature != nil`). If so, it uses `ParseTagWithSignature` to verify the tag's signature and populates the `verification` field from the tag. Otherwise, it falls back to the commit signature (existing behavior for unsigned/lightweight tags).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12351
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
|
||
|
Thomas Teixeira
|
731334e973 |
fix(web): org projects assignment in issue view (#7999)
Allows user to assign organization projects to their new issues, using the project sidebar selector, even when repository's projects are disabled. Moreover, the project sidebar selector is now hidden if no projects (repository-wide + organization-wide) are available. Fixes forgejo/forgejo#5666 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7999 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Gusted
|
07a6b6ce82 |
chore: make use of go1.26 features (#12369)
Allows us to make use of Go features introduced in v1.26. I require a feature from v1.26 for a PR I want to make later. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12369 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Nils Goroll
|
9d323c5125 |
chore: remove #11024 workarounds (#12301)
remove two workarounds which are not required any more Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12301 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Andreas Ahlenstorf
|
d867b25e72 |
chore: replace github.com/robfig/cron/v3 (#12365)
github.com/robfig/cron is used for parsing cron schedules of scheduled Forgejo Actions workflows. It has not seen an update in roughly six years and looks abandoned. There are multiple code paths that trigger panics instead of errors. It is replaced by github.com/gdgvda/cron, which is one of the few maintained forks. github.com/gdgvda/cron was picked because its behaviour is fully backwards-compatible and the developers are responsive. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12365 Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org> Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
7fc236c589 |
feat: allow Forgejo Actions to be used an Authorized Integration in-memory with internal issuer (#12364)
Allow JWTs that are generated by Forgejo Actions to be validated within Forgejo in-memory. Without any special support for this internal access situation, these problems would occur: 1. Forgejo would need to make an HTTP request to itself to get the valid public key for the JWT, in order to validate its signature. This is a waste of resources, and introduces a self-DoS risk. 2. Forgejo would need to be available via TLS in order for Actions to make service calls to Forgejo with that JWT, due to the TLS requirement for public key fetching. This would be a blocker for writing end-to-end tests for Forgejo, but also would affect users who do not host Forgejo with TLS. 3. Authorized Integrations would need to be saved with the `issuer` URL of Forgejo. If Forgejo's own `setting.AppURL` changed, all the persisted records in the database would become incorrect. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12364 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
be3fe4ff60 |
feat: allow Authorized Integrations to authenticate to Forgejo's package registries (#12310)
Enables and tests the usage of Authorized Integrations to access the package registries. Specific testing includes: - Container registry -- automated testing and manual testing - Generic registry, w/ detailed authorization tests -- automated testing - Conan registry -- automated testing (uses an "authenticate" endpoint that required updates) - npm registry -- manual testing with a Forgejo Action publishing packages For the container & conan registeries, where the client uses an authentication endpoint to request a temporary access token, the expiry of the temporary access token is restricted to the expiry of the authorized integration's JWT for the authorized integration in order to prevent an escalation of privileges. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [ ] `make pr-go` before pushing ### 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12310 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
733a390ecd |
fix: verify PR author has write access to head to support allow maintainers edit (#12292)
When a pull request is opened, the author is able to mark that pull request to "Allow edits from maintainers", which grants the maintainers of the pull request's repo access to edit the pull request branch contents. It is possible to create a pull request where the pull request author does not have the ability to edit the pull request branch. Due to a missing security check for this case, maintainers of the pull request repo would be granted the ability to edit the pull request branch, even if the author of the pull request did not have that ability. By exploiting this missing security check, a user can edit any branch in a repository if they're able to fork that repository. The issue is being fixed by restricting the scope of "Allow edits from maintainers" to only grant that access if the pull request author also had access to edit the branch. Thanks to Arvin Shivram of Brutecat Security for discovering and responsibly disclosing the vulnerability. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12292 Reviewed-by: 0ko <0ko@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
70f7260e66 |
feat: add CLI command 'admin user create-authorized-integration' (#12299)
Allows the creation of an authorized integration as a Forgejo administrator, either for development testing or to support server-automation. Clipping out the CLI config options, looks like:
```
NAME:
forgejo admin user create-authorized-integration - Create an authorized integration for a specific user
USAGE:
forgejo admin user create-authorized-integration [options]
OPTIONS:
--username string, -u string Username
--issuer string JWT issuer ('iss' claim), example: https://forgejo.example.org/api/actions
--claim-eq string=string [ --claim-eq string=string ] Zero-or-more claim equality checks, formatted as claim=value, example: "actor=someuser"
--claim-glob string=string [ --claim-glob string=string ] Zero-or-more claim glob checks, formatted as claim=value, example: "sub=repo:forgejo/*:pull_request"
--scope string [ --scope string ] One-or-more scopes to apply to access token, examples: "all", "read:issue", "write:repository" (default: "all")
--repo string [ --repo string ] Zero-or-more specific repositories that can be accessed, or "all" to allow access to all repositories, example: "owner1/repo1" (default: "all")
```
As an example, this will create an authorized integration that will permit Codeberg's Forgejo Actions to generate trusted JWTs that can access the local user `mfenniak`:
```bash
$ ./forgejo admin user create-authorized-integration \
--username mfenniak \
--issuer https://codeberg.org/api/actions \
--claim-eq sub=repo:mfenniak/forgejo-runner-testrepo:pull_request \
--scope read:user
{
"message": "Authorized integration was successfully created.",
"issuer": "https://codeberg.org/api/actions",
"audience": "u:1:c97d83bc-fa4e-4db3-b898-414cd5b6ce33",
"claim_rules": [
{
"description": "\"sub\" = \"repo:mfenniak/forgejo-runner-testrepo:pull_request\"",
"claim": "sub",
"compare": "eq",
"value": "repo:mfenniak/forgejo-runner-testrepo:pull_request"
}
]
}
```
The output is a JSON document to aid in use in automation. The `audience` field is the audience generated by Forgejo that must be used by the remote to generate the JWT. Continuing this example to the client-side, a matching Forgejo Action like this in the `mfenniak/forgejo-runner-testrepo` repo, for a `pull_request` event, then it will be able to access the Forgejo server that the authorized integration was created on like this:
```yaml
on:
pull_request:
enable-openid-connect: true
jobs:
job1:
runs-on: docker
steps:
- name: Fetch JWT
id: jwt
run: |
set -eux -o pipefail
set +x
jwt=$(curl --fail \
-H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=u:1:c97d83bc-fa4e-4db3-b898-414cd5b6ce33" \
| jq -r ".value")
echo "::add-mask::$jwt"
set -x
echo "jwt=$jwt" >> $FORGEJO_OUTPUT
- name: API call to Forgejo
run: |
curl \
-v --fail \
-H "Authorization: bearer ${{ steps.jwt.outputs.jwt }}" \
"https://example.org/api/v1/user" | jq
```
CLI command is tested manually. Supporting functions have associated unit tests.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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.
- CLI update should be automatic in docs -- more detailed Authorized Integration documentation is on my project plan.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12299
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
|
||
|
Mathieu Fenniak
|
37412e6a00 |
feat: cache OIDC metadata & JWKS when read by authorized integration (#12275)
Enhances authorized integrations (#12261) with a cache of the remote OpenID Connect descriptor file and JSON Web Key Set (JWKS), improving runtime performance and reducing intermittent reliability risks. By default a 10 minute cache is used, configurable through `[authorized_integration].CACHE_TTL`. To mock the cache for testing, mockery code generation is added, and a previous manually generated mock for `AuthorizationReducer` was replaced with the code generation. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. - Authorized integrations are not yet exposed to end-users. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12275 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Nils Goroll
|
93296305f9 |
fix test: revert unneeded test change with unintended consequences (#12281)
... from #11194 /
|
||
|
Gabor Pihaj
|
73b30acbd0 |
feat: replace repo based server-side hooks with centralised hooks (#10397)
This PR is replacing repository based hooks hooks with centralised files, this way the files don't need to be copied into every repository, only one line of config need to be added in the repository. Closes: #3523 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10397 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
900306e65a |
feat: add repo-specific & public-only authz reducers to authorized integrations (#12267)
Built on #12266; one commit added. Adds the ability to reduce the authorization scope of an authorized integration to public-only resources and repo-specific resources. Backend only -- no frontend created yet. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - 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 ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12267 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
c9d8682f90 |
test: add API integration testing for authorized integration authentication (#12266)
Built on #12261; one commit added. Adds an integration test verifying that access to the API can be authenticated by an authorized integration. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - 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 ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12266 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
48218c654b |
feat: authorized integrations DB models and authentication implementation (#12261)
Authorized Integrations is a new feature to allow users to define external systems which can generate JSON Web Tokens (JWTs) that Forgejo will trust in order to perform API access on behalf of that user. This is an authentication mechanism that requires zero preconfiguration of shared secrets, and instead establishes trust through short-lived secrets (JWTs) that are signed by the issuer, signatures are validated by comparison with published public keys, and a public-keys retrieved through well-known HTTP endpoints secured with TLS verification. The primary goal of Authorized Integrations is to support a mechanism for Forgejo Actions to receive elevated, but controlled, additional access to Forgejo. More details as to what the end result will look like are available in the [design proposal](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-13268004) on #3571. This PR adds the core database storage and authentication verification for Authorized Integrations, with these capabilities: - An Authorized Integration is resolved by a unique key of an "issuer" and an "audience". The value of "issuer" is defined by the remote integration, and the value of "audience" will incorporate a unique identifier generated by Forgejo. - Example issuer: `https://token.actions.githubusercontent.com/` is the issuer for GitHub JWTs - Example audience: `https://forgejo.example.org/-/mfenniak/authorized-integration/6cc55ba0` is the expected format for a random audience field that Forgejo will generate. - JWTs can contain any number of claims, which are represented as a JSON object; Forgejo can validate these with a flexible policy. - eg. a claim may be `{"sub": "repo:coolguy/forgejo-runner-testrepo:pull_request"}` indicating that an OIDC token was received from an Actions execution in a specific repo on a specific event. - Authorized Integrations support a `ClaimRules` system which allows claim equal, glob, and nested object inspection. - `{"claim":"sub","comparison":"eq","value":"repo:mfenniak/forgejo-runner-testrepo:pull_request"}` -- would validate that `sub` exactly equals the specific value - `{"claim":"sub","comparison":"glob","value":"repo:mfenniak/forgejo-runner-testrepo:*"}` -- would validate that `sub` matches the given string prefix but allow any event - When a JWT is received on an incoming API call, Forgejo retrieves the Authorized Integration from the DB (if present), validates the token signature against a remote JWKS, validates the claims, and grants API access as the user with a permission scope defined on the Authorized Integration. In addition to the unit testing provided here, this PR has been manually integration tested against three JWT issuing systems: Forgejo Actions, GitHub Actions, and AWS STS GetWebIdentityToken. Careful consideration has been made of these security concerns: - SSRF attacks against Forgejo are prevented by: - having a blocklist on remote HTTP validation requests which prevent access to internal network resources, - ensuring that authorized integrations are created by users with matching issuers, before attempting to validate tokens - Resource utilization attacks against Forgejo are reduced by limiting the possible size of external metadata requests; when fetching `/.well-known/openid-configuration` and `jkws_uri`'s from remote, untrusted servers, a maximum response size of 16 kB is enforced - Only well-known secure assymmetric JWT signing algorithms are supported -- in particular, the sketchy `none` JWT algorithm isn't supported. - JWT validation is covered by extensive unit tests, covering validation of all JWT timestamps, validation of the issuers, validation of the issuer's documented supported signing algorithms. This PR serves as a core, and many enhancements are required for this to be a usable system for users. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [ ] `make pr-go` before pushing ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - Documentation updates for new config entries will be authored. - [ ] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. - Marking not visible as there's no mechanism to interact with this backend yet. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12261 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
ef5479af71 |
refactor: split "basic" and "oauth2" authentication impl into smaller single-purpose components (#12236)
Forgejo's `basic` and `oauth2` authentication methods perform five distinct types of authentication:
- Username and password authentication
- Personal access tokens
- OAuth2 access tokens
- Forgejo Action's `${{ forgejo.token }}` -- task-based static tokens
- Forgejo Action's `${{ env.ACTIONS_RUNTIME_TOKEN }}` JWT, which is the authentication method used for `upload-artifact` (mirroring GitHub's implementation)
`basic` and `oauth2` both supported almost all of these methods, resulting in quite a bit of code duplication between them. This PR splits personal access tokens into `access_token.go`, Action's task-based tokens into `action_task_token.go`, and Action's JWT tokens into `action_runtime_token.go`.
**Note:** There is one peculiar side-effect that is worth discussing. Previously, `Authorization: Basic ...` was handled by one complex code path in basic.go, and `Authorization: Bearer ...` was handled by another in oauth2.go, and if authorization failed and a 401 was returned, a single error message would be returned to the user. Now, as multiple authorization methods may look at `Authorization: Basic ...` and provide their own reason why authorization didn't work, a 401 response has multiple reasons for a lack of authorization listed:
```
401 Unauthorized
...
failure to authenticate with oauth2 access token: not a JWT
Basic authorization is not allowed while having security keys enrolled
access token does not exist [sha: notpassword]
task with token "notpassword": resource does not exist
```
A couple tests have been adapted to check that the result contains their expected response, rather than is equal-to or prefixed-with their expected result. This is caused by the "auth group" joining together any "invalid credentials" errors, and, to a certain extent it is useful to understand why the authorization request failed. But it's a bit obscure as well.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- Relying on integration testing for regression checks.
- I ran...
- [x] `make pr-go` before pushing
### 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.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12236
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
|
||
|
Andreas Ahlenstorf
|
db622afd87 |
refactor: delegate to service for run cancellation (#12142)
## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes (can be removed for JavaScript changes) - I added test coverage for Go changes... - [ ] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes (can be removed for Go changes) - 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. *The decision if the pull request will be shown in the release notes is up to the mergers / release team.* The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12142 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
9f7533c1f1 |
refactor: clarify four different outputs that authentication methods provide (#12231)
#12202 began a refactor of Forgejo's authentication implementations by providing structured data on an authentication success. However, error cases were maintained as-is in that refactor, leaving a complex situation: what does returning an error from an authentication method mean?; does it mean that the authentication failed, or that a server error occurred? Can another authentication still be tried? This PR changes authentication methods so that they can return one of four things: - `AuthenticationSuccess` with an authentication result. - `AuthenticationNotAttempted` which indicates that no credentials relevant for this authentication method were presented. If every method returned `AuthenticationNotAttempted`, then you would have an unauthenticated access. - `AuthenticationAttemptedIncorrectCredential` which indicates that credentials were present and failed validation -- a situation indicating a `401 Unauthorized`. - `AuthenticationError` which indicates that an internal server error occurred and failed authentication -- indicating a `500 Internal Server Error`. This paves the way for one more refactor coming next: `basic.go` and `oauth2.go` perform 3-4 different authentications each (access tokens, oauth JWTs, actions tokens, actions JWTs, and username/password). With the capability to return these more precise responses, these authentication methods can be split up into separate logic that isn't intertwined together. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [ ] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - Relying on existing test suite, with changes for any compile errors -- the next refactor will simplify the auth methods so that they can be unit tested easily. - I ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12231 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
1ddd5faa5c |
refactor: change authentication to return structured data (#12202)
Currently authentication methods return information in two forms: they return who was authenticated as a `*user_model.User`, and then they insert key-values into `ctx.Data` which has critical impact on how the authenticated request is treated. This PR changes the authentication methods to return structured data in the form of an `AuthenticationResult`, with all the key-value information in `ctx.Data` being moved into methods on the `AuthenticationResult` interface. Authentication workflows in Forgejo are a real mess. This is the first step in trying to clean it up and make the code predictable and reasonable, and is both follow-up work that was identified from the repo-specific access tokens (where the `"ApiTokenReducer"` key-value was added), and is pre-requisite work to future JWT enhancements that are [being discussed](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-13268004). ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [ ] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - All changes, at least in theory, are refactors of existing logic and are not expected to have functional deviations -- existing regression tests are the only planned testing. - I ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12202 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
2ed98ac848 |
fix: resolve outer workflow call to success, not failure, on inner job skip (#12224)
If one or more of a workflow expansion's inner jobs are status "skipped", consider that as a success, rather than a failure. Fixes https://code.forgejo.org/forgejo/runner/issues/1490. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### 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. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12224 Reviewed-by: Michael Kriese <michael.kriese@gmx.de> Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |