Forgejo monthly report - August 2025

The monthly report is meant to provide a good overview of what has changed in Forgejo in the past month. If you would like to help, please get in touch in the chatroom or participate in the ongoing discussions.

Releases

Forgejo security release

The security team has been busy with the fixes that were announced and published in Forgejo v11.0.4 and v12.0.2.

When preparing multiple pull request in advance and in secret, the challenge is to make sure that no unexpected conflicts will arise when they are added to the Forgejo repository, shortly before the release is published. And also to account for the time it takes for the CI to verify a total of 26 pull requests (including backports) knowing each run takes around 30 minutes. It turned out to be around 12 hours of real time, including delays due to errors. There were a few issues (two pull requests required manual merges, some trivial conflict resolution were missed) but their resolution was not too time consuming.

A decision on when and why security releases should be published, has to strike a balance between:

  • the severity and impact of each vulnerability (e.g. for web endpoints vulnerable to manually crafted identifiers the impact and severity is higher than for this cross-site scripting (XSS) vulnerability).
  • the frequency of security releases because they can be exhausting for Forgejo admins when there are too many.
  • the risk of regressions when backporting the fix because it is done in secret and does not benefit from the wider panel of reviewers as the backport worked on publicly.
  • the attention it requires from Forgejo admins when the vulnerability is difficult to understand, even when the release notes are crystal clear.

For these releases, the decision was made to publish an unusually large number of security fixes (nine) in a single release because:

  • the severity of each of them is not too high (e.g. compared to the release fixing web endpoints vulnerable to manually crafted identifiers that was published last year).
  • spreading them on two or three security release would be more work for the Forgejo admins.
  • only three manual backports out of eighteen are conflicting and the resolution is trivial which reduces the risk of regressions.

The release notes were unified and worded so that the fix is explained first (present tense) and the vulnerability is explained last (past tense) in the hope that it makes them quicker to evaluate and understand.

Helm chart

Helm chart v14 was released on 22. August. This release removes the PostgreSQL and Valkey sub charts. This means that if you are using them, please check the migration guide before upgrading.

As usual, a new minor version (v14.0.1) was also published as the corresponding release to the Forgejo v12.0.2 security release.

Forgejo runner v10

As the year long effort to fix security issues came to an end, the warning about the Forgejo runner being insecure was removed. Security issues are now expected to be reported as per the Forgejo security policy.

The Forgejo security team organized itself with the necessary infrastructure to prepare security fixes under embargo in a private repository. The first of which was announced 22 August and published 1 September.

A regression in v10.0.0 was discovered minutes after it was published. Luckily it as an easy fix and v10.0.1 was published an hour later. The post-mortem of this unfortunate event is rather simple: despite very thorough reviews and extensive automated testing, bugs happen.

Discussions

AI usage in the context of Forgejo

As announced in the previous monthly report, a discussion about how to handle AI contributions began in the Forgejo space at the end of June. A vote was held on the proposals that emerged, and the documentation of the results is currently in progress.

Drafts have been created for the governance and Code of Conduct additions. Only minor details are left to be discussed as part of the documentation and implementation process.

Forgejo runner

As the runner becomes more stable and usable outside the context of the Forgejo project itself, it needs more contributors and a healthy momentum. A discussion started on how to achieve that and at the same time a significant effort was made that successfully increased the activity and allowed new contributors to be onboarded. Maintaining this momentum will be the main challenge of the coming months.

Although features are not the priority, there was an exception: reusable workflows. They were partially implemented and not supported until Forgejo runner v9.1.0 released this month. The main reason for this exception is that, although undocumented and partially working, it was used and bug reports were received. The difficult choice was between removing support for the partial implementation, thus breaking existing workflows that managed to find a happy path or completing the implementation so it could be supported.

Schema validation of actions and workflows

As expected, the schema validation introduced in Forgejo runner v8.0.0 caused some legitimate workflow to fail and the schemas had to be fixed. As of Forgejo runner 9.1.1, all known issues were fixed and there has been no report of unexpected validation failures in the past two weeks.

While investigating a validation error, a bug in the Go YAML package was discovered and reported. Until a fix is available, a simple workaround can be applied: remove the leading empty line. On that occasion it was also discovered that invalid scheduled workflows could block other scheduled workflows and a fix was backported to Forgejo v12 released 31 August.

Codebase re-organization

The activity in Netkos ACT has been low since the beginning of 2024. The main contributor also created a fork but it did not receive much attention in the past six months. In that context a cooperation with an actively maintained codebase seems unlikely.

As all commits from Nektos or Gitea were either ported or cherry-picked in Forgejo, it appeared that it would be easier to maintain a single codebase rather than two separate repositories (runner and ACT). The two repositories were merged on 28 July and the former ACT repository was archived.

actions/artifact@v4 support

The actions/artifact@v4 is used to add files to a job run. It relies on an ad-hoc protocol that is different from anything else and was introduced in Forgejo at the beginning of 2024. It is very useful and frequently used.

Unfortunately the choice to support it by implementing the protocol means that Forgejo is forced to chase and reverse engineer the GitHub server implementation for which only the client side is available under a Free Software license.

Two concrete side effect of that decision are:

  • the need to maintain a fork of the action that disables GitHub specific verification preventing it from running on GitHub Enterprise and therefore any self-hosted forge.
  • the need to introduce breaking changes with Forgejo v13 to fix some bugs.

Licensing

A discussion started to change the license of the runner to GPLv3+. It is in line with the licensing agreement of the Forgejo project and no concerns were raised. But, as it is an important decision, it takes a few weeks to be merged and implemented.

Federation

For a high-level overview, check out the federation roadmap.

The work to implement federated user following continued (see the merged pull requests 1, 2). The latest pull request is still in review as preliminary manual testing using Mastodon instead of GtS discovered a bug.

Collecting test coverage for the implementation of federation requires obtaining data from both the Forgejo repository (unit and integration tests) and the end-to-end repository (where GtS is run alongside Forgejo and plays a realistic scenario). When running out of a pull request end-to-end tests now upload coverage data as artifacts to the CI run. They can then be downloaded and manually merged out of a new workflow run of the tests that also uploads the result as an artifact. This would benefit from being automated to be more generally useful but it already allowed for verifying which parts of the federation codebase deserve more testing.

Other

Blog post and talk about Federation

On 14 August 2025, a blog post explained how to experiment with the current implementation of user following.
On 16 August 2025, Jerger held a talk (in German) about federated forgejo at the FrOSCon in Bonn, Germany. It provided insights into the engine room, security considerations, challenges, and the way forward.

FFmpeg using Forgejo

FFmpeg announced in a recent news article that they started to accept contributions via their Forgejo instance available at code.ffmpeg.org. We are pleased by such announcements because they show the results of our daily work.

Matrix security disclosure

On 16 July 2025, Matrix announced in a predisclosure that a security vulnerability had been found in the current room versions and that it had been fixed. For us, this means that all rooms on Matrix must be updated.

As announced in the last monthly report we planned to do the upgrade shortly after the security fix was released. However, the publication and adoption of the security fix didn’t go as we expected. As a result, only one room has been updated so far.

We are monitoring the adoption of the security fix and plan to complete the remaining updates soon. An announcement will be made in every room before it is updated.

We Forge

Forgejo is a community of people who contribute in an inclusive environment. We forge on an equal footing, by reporting a bug, voicing an idea in the chatroom or implementing a new feature. The following list of contributors is intended to reflect this diversity and to acknowledge all the contributions made over the past month. If you are missing, please ask for an update.