Forgejo 12.0.0 → 13.0.0

Insecure authentication methods have been deprecated since 2023. They were removed in v12.0.0 but they were restored in v12.0.1. Certain OAuth2 clients and packages in the Forgejo ecosystem still rely on these methods and it was premature to remove them.

Detailed comments on security bug fixes

• PR (backported): fix: email comments are removed from email addresses When registering with an email account including a comment (e.g. me@example.com (a comment here)), the comment is removed from the email address. It was possible to include an email address in the comment to bypass the block list. For instance if registering with me@evilcorp.com (me@example.com) the mail would incorrectly be verified against the block list using the comment instead of @evilcorp.com. This is a regression introduced in Forgejo v12.
• PR (backported): fix: validate CSRF on non-safe methods All PUT/DELETE routes in the web UI are validated to prevent a cross site request forgery. Although all POST routes are validated with a CSRF token, some of the PUT/DELETE routes were missing this validation.
• PR (backported): fix: use credential helpers for git clones When performing a git clone that requires credentials, they are temporarily stored in files and used with Git credential. They were previously included in the URL that were readable by a user with shell access to the host running the Forgejo instance when, for instance, they ask for the list of process (ps).
• PR (backported): fix: consistently enforce 2FA on OpenID 2.0
• PR (backported): fix: delete old auth token upon replacing primary email When the primary email is changed before it is validated, the URL sent for validation purposes must be invalidated. It was previously possible use to delay use of the URL to validate the primary email and modify the primary email in the meantime. It allowed to validate the newer primary email using the older primary email, effectively bypassing validation.
• PR (backported): fix: require password login for creation of new token Obtaining a personal access token via the API is no longer possible if the password used for basic authentication is an API token or an OAuth2 token: it has to be the user password. Such privilege escalation was only possible for tokens with write permissions to the user. This requirement is already enforced when API calls are made with an authorization header as described in the documentation, but it was not enforced with basic authentication. As a consequence it was possible for an API token with write:user permissions or an OAuth2 token to obtain a new token with a wider or identical scope.
• PR (backported): fix: ensure GetUserByEmail only considers validated emails Only validated emails can be used to:

• assert if a signature can be trusted or,
• to assign comments, issues to an existing user during a migration

The emails that were not yet validated could previously used as if they were validated, incorrectly showing commits as trusted or assigning comments, issues to the user associated with this email during migrations.

Existing migrations are not modified when they were incorrectly assigned to an email that is not validated. The trust status of all commit signatures will now show differently depending on the validation status of an email.

• PR (backported): fix: don't allow credentials in migrate/push mirror URL It is no longer possible to specify the user and password when providing a URL for migrating a repository, the fields dedicated to that purpose on the form must be used instead. This is to prevent that those credentials are displayed in the repository settings that are visible by the repository admins, in the case where the migration is a mirror.
• PR (backported): fix: only redirect to a new owner (organization or user) if the user has permissions to view the new owner

A companion blog post provides additional context on this major release.

This release contains a regression when RENDER_CONTENT_MODE = iframe is set in app.ini that sometime forces the height to be 300px. It will be fixed in Forgejo v13.0.1.

• Breaking features
• PR: bump the minimum required Git version from 2.0.0 to 2.34.1
• PR: Forgejo Actions workflows are verified with a YAML schema and common errors such as using an incorrect context (e.g. ${{ badcontext.FORGEJO_REPOSITORY }}) or a typo in a required keyword (e.g. ruins-on: instead of runs-on:) will be reported in the action page and the web page that displays the file in the repository. It is recommended to verify existing workflows are successfully verified prior to upgrading, as explained in the Forgejo runner release notes.

• Breaking bug fixes
• PR: The artifact-url ouput returned by the upload-artifact@v4 action can be used to download the artifact. It was previously 404. To implement this compatibility fix, the web UI URL to download artifacts (i.e. /{owner}/{repo}/actions/runs/{run_id}/artifacts/{artifact_name}) now relies on an identifier that is unique accross the instance. URLs to download artifacts that were bookmarked or copied prior to this change use an id relative to the repository and will no longer work. It previously was /{owner}/{repo}/actions/runs/{run_index}/artifacts/{artifact_name}, note the difference between {run_id} and {run_index}. The new URL can be obtained again by visiting the parent page, which still uses the relative id (/{owner}/{repo}/actions/runs/{run_index}).