42
21
Fork
You've already forked sustainability
9

Public institution is interested in Forgejo; what do you want to see supported? #163

Open
opened 2026年02月11日 00:01:32 +01:00 by n0toose · 11 comments
Member
Copy link

Hi all. Shortly before FOSDEM, I was messaged by a member of the free and open-source software community (with a background in promoting said software; we had briefly communicated before) that planned a meeting with an official who, in a previous brief conversation, expressed interest in "get some wheels moving" to financially support Codeberg and Forgejo. They suggested to meet the next day–completely out of the blue–but I took it very seriously, so I gathered a set of people contributing to both projects and we answered questions about e.g. both projects’ governance, relationship and progress in a non-binding fashion–we talked about how the projects work, so that they’d be prepared for the meeting.

Now, the person we met with got back to us with a question that I wish to relay to the greater Forgejo community: Can you help us compile a list of things that you would like to see supported (financially/materially)? Just a small line describing each thing with few words, together with a rough time/material estimate (if possible). Such things could include e.g. goalposts related to federation, moderation, UI/UX, whatever–this is not for a grant with a limited scope: The more, the merrier. It doesn’t matter if you contribute personally or not, but if you do, you might have greater insights that e.g. I don’t. Personal opinions can help compared to e.g. linking every issue in Forgejo’s issue trackers :)


For now, I was asked to not disclose the name of the institution yet. I understand that my request is unorthodox and vague, so I will try to justify it: This is not a request to help form a concrete proposal to be submitted–this is not for a typical grant application (or any grant at all). It’s pure spitballing. All discussions are informal and in early stages, but there is potential that they can turn formal–for which I’d like assistance, so that more points of view can be represented, up until the point where it all starts to take form and "become formal" (instead of following a "black box process" until the "output" is ready to be shared as part of a proposal that would've appeared out of nowhere)–then it will be the right time. Given the irregularity of the situation and the sensitiveness, I was (and still kind of am) worried about getting the transparency aspects right, especially as it has been a subject of mild controversy in the past. Before I wrote this, I checked with two Forgejo contributors (that I’d rather not name) and got the impression that this is fine under the circumstances, as long as I explain–if this turns out to not represent consensus, we’re open to feedback.

If you're in any way interested about the circumstances, I have prepared a set of bullet points here.
  • During FOSDEM, we met someone (who had pre-planned to meet an official the next day) to talk about Codeberg/Forgejo. We gave non-binding information and context about governance and sustainability. They appeared enthusiastic and experienced, as well as curious as to where things stood. However, none of us were in the meeting with the official; the circumstances differ to those when we met an official virtually (and kept notes).
    • I have been reassured that the character was, is, and would remain non-binding for a while, but gathered contributors of Codeberg and Forgejo "just to be safe". "Non-binding" also means "unofficial", "very early", etc. -> hence why "best not to say anything before this takes
    • No side involved has a concept of the scope/goals/goalposts yet; all of this is informal and "unserious", but responses could help this take form. I think there is potential, but it might be a nothingburger. I only know "who met with whom", the institution and that there’s interest. I think that’s the most anyone knows, the official
    • I wrote this text on my own accord, but didn’t e.g. seek out everyone’s permission to be named (I only got permission to name @dpk so far) and didn’t have the energy to do so, so I have omitted the names for now; I can ask for permission to share them if requested. I stated that I am neither representing Codeberg’s Presidium nor the Forgejo project/community singlehandedly, and I’d like to reiterate that this applies to the text I wrote as well.
  • Even if "this doesn’t go anywhere in the end", I hope that it might raise some light on some underrepresented aspects.

My goal is not to make anyone here feel uneasy, so if there are any questions or concerns, feel free to reach out–I expect that others with knowledge of the events might be able to add something as well. I can provide some additional context in private (what I omitted here), but I’d ask that you don’t share publicly so as to not put the third party in a difficult position.

If there’s any concerns or questions, feel free to reach out. It might take a few days for me to respond at the moment.

Hi all. Shortly before FOSDEM, I was messaged by a member of the free and open-source software community (with a background in promoting said software; we had briefly communicated before) that planned a meeting with an official who, in a previous brief conversation, expressed interest in "get some wheels moving" to financially support Codeberg and Forgejo. They suggested to meet the next day–completely out of the blue–but I took it very seriously, so I gathered a set of people contributing to both projects and we answered questions about e.g. both projects’ governance, relationship and progress in a non-binding fashion–we talked about how the projects work, so that they’d be prepared for the meeting. Now, the person we met with got back to us with a question that I wish to relay to the greater Forgejo community: **Can you help us compile a list of things that you would like to see supported (financially/materially)?** Just a small line describing each thing with few words, together with a rough time/material estimate (if possible). Such things could include e.g. goalposts related to federation, moderation, UI/UX, whatever–this is not for a grant with a limited scope: The more, the merrier. It doesn’t matter if you contribute personally or not, but if you do, you might have greater insights that e.g. I don’t. Personal opinions can help compared to e.g. linking every issue in Forgejo’s issue trackers :) --- For now, I was asked to not disclose the name of the institution yet. I understand that my request is unorthodox and vague, so I will try to justify it: This is not a request to help form a concrete proposal to be submitted–this is not for a typical grant application (or any grant at all). It’s pure spitballing. All discussions are informal and in early stages, but there is potential that they can turn formal–for which I’d like assistance, so that more points of view can be represented, up until the point where it all starts to take form and "become formal" (instead of following a "black box process" until the "output" is ready to be shared as part of a proposal that would've appeared out of nowhere)–then it will be the right time. Given the irregularity of the situation and the sensitiveness, I was (and still kind of am) worried about getting the transparency aspects right, especially as it has been a subject of mild controversy in the past. Before I wrote this, I checked with two Forgejo contributors (that I’d rather not name) and got the impression that this is fine under the circumstances, as long as I explain–if this turns out to not represent consensus, we’re open to feedback. <details> <summary>If you're in any way interested about the circumstances, I have prepared a set of bullet points here.</summary> - During FOSDEM, we met someone (who had pre-planned to meet an official the next day) to talk about Codeberg/Forgejo. We gave non-binding information and context about governance and sustainability. They appeared enthusiastic and experienced, as well as curious as to where things stood. However, none of us were in the meeting with the official; the circumstances differ to those when we met an official virtually (and kept notes). - I have been reassured that the character was, is, and would remain non-binding for a while, but gathered contributors of Codeberg and Forgejo "just to be safe". "Non-binding" also means "unofficial", "very early", etc. -> hence why "best not to say anything before this takes - No side involved has a concept of the scope/goals/goalposts yet; all of this is informal and "unserious", but responses could help this take form. I think there is potential, but it might be a nothingburger. I only know "who met with whom", the institution and that there’s interest. I think that’s the most anyone knows, the official - I wrote this text on my own accord, but didn’t e.g. seek out everyone’s permission to be named (I only got permission to name @dpk so far) and didn’t have the energy to do so, so I have omitted the names for now; I can ask for permission to share them if requested. I stated that I am neither representing Codeberg’s Presidium nor the Forgejo project/community singlehandedly, and I’d like to reiterate that this applies to the text I wrote as well. - Even if "this doesn’t go anywhere in the end", I hope that it might raise some light on some underrepresented aspects. </details> My goal is not to make anyone here feel uneasy, so if there are any questions or concerns, feel free to reach out–I expect that others with knowledge of the events might be able to add something as well. I can provide some additional context in private (what I omitted here), but I’d ask that you don’t share publicly so as to not put the third party in a difficult position. If there’s any concerns or questions, feel free to reach out. It might take a few days for me to respond at the moment.
  • In Forgejo Actions, we rely on GitHub to maintain the actual actions that is typically used to perform work (eg. actions/checkout@v4). There are features missing in these actions, such as support for sha256 repos, support for executing without node.js, support for operating over multiple forges. We've hesitated to fork or re-implement them due to the lack of people-power to support the effort.
  • There are areas where Forgejo's static UI creates unexpected user experience for people coming from other platforms; for example, the "commit statuses" section of a pull request having no dynamic nature to it. Select areas like this getting a revisit with careful dynamism would be useful.
  • Better tools for managing change reviews (changesets, stacked pull requested) are a major topic that surfaces frequently.
  • Professional software pentesting may be a valuable investment to reduce the risk of severe security issues in Forgejo. This is an effort that, if taken up, is best served with long-term investment (eg. annual pentests), not a one-time effort.
- In Forgejo Actions, we rely on GitHub to maintain the actual actions that is typically used to perform work (eg. `actions/checkout@v4`). There are features missing in these actions, such as support for sha256 repos, support for executing without node.js, support for operating over multiple forges. We've hesitated to fork or re-implement them due to the lack of people-power to support the effort. - There are areas where Forgejo's static UI creates unexpected user experience for people coming from other platforms; for example, the "commit statuses" section of a pull request having no dynamic nature to it. Select areas like this getting a revisit with careful dynamism would be useful. - Better tools for managing change reviews (changesets, stacked pull requested) are a major topic that surfaces frequently. - Professional software pentesting *may* be a valuable investment to reduce the risk of severe security issues in Forgejo. This is an effort that, if taken up, is best served with long-term investment (eg. annual pentests), not a one-time effort.
Member
Copy link

@mfenniak wrote in #163 (comment):

  • Professional software pentesting may be a valuable investment to reduce the risk of severe security issues in Forgejo. This is an effort that, if taken up, is best served with long-term investment (eg. annual pentests), not a one-time effort.

Along these lines, I think it would be beneficial for whoever is contracted to supply some security engineering courses + materials for Forgejo maintainers/contributors. I think maintainers have a good eye for security issues, it would just be nice to have some additional resources. Depends on how viable that is cost-wise, though.

Prior to a pentest, we should probably also survey the codebase for interfaces that handle user-input, and add fuzz test harnesses for all of them.

It is relatively low-hanging fruit, and would provide a good basis for an initial pentest (we get more value the more automated security tools we can incorporate). This approach would allow the contracted pentest provider to focus on tasks that actually require skilled manual tests.

We have a few basic fuzz harnesses, but could definitely benefit from adding more.

@mfenniak wrote in https://codeberg.org/forgejo/sustainability/issues/163#issuecomment-10507514: > * Professional software pentesting _may_ be a valuable investment to reduce the risk of severe security issues in Forgejo. This is an effort that, if taken up, is best served with long-term investment (eg. annual pentests), not a one-time effort. Along these lines, I think it would be beneficial for whoever is contracted to supply some security engineering courses + materials for Forgejo maintainers/contributors. I think maintainers have a good eye for security issues, it would just be nice to have some additional resources. Depends on how viable that is cost-wise, though. Prior to a pentest, we should probably also survey the codebase for interfaces that handle user-input, and add fuzz test harnesses for all of them. It is relatively low-hanging fruit, and would provide a good basis for an initial pentest (we get more value the more automated security tools we can incorporate). This approach would allow the contracted pentest provider to focus on tasks that actually require skilled manual tests. We have a few basic fuzz harnesses, but could definitely benefit from adding more.
Author
Member
Copy link

Okay, so far the initial feedback that has come in doesn't completely match the "sentence, few words, (ballpark estimation of) hours"–but that's fine, we can figure it out later. For now, documenting things that are otherwise niche and not as attention-grabbing/grant-attracting as "forge federation" (although such concrete recommendations are still very much welcome!) is very valuable.


I'll continue:

  • Building, integrating and distributing security integrations in Forgejo – Certain Linux/FreeBSD mechanisms, like "Landlock", "unveil" or "seccomp", help prevent system compromise (e.g. access to all files) if an application, like Forgejo, gets compromised. Those require careful engineering, large-scale testing and distribution. (160h)

(Disclaimer: I have explored Landlock before myself, but haven't had the concentration to make it "workable".)

Okay, so far the initial feedback that has come in doesn't completely match the "sentence, few words, (ballpark estimation of) hours"–but that's fine, we can figure it out later. For now, documenting things that are otherwise niche and not as attention-grabbing/grant-attracting as "forge federation" (although such concrete recommendations are still very much welcome!) is very valuable. --- I'll continue: - Building, integrating and distributing security integrations in Forgejo – Certain Linux/FreeBSD mechanisms, like "Landlock", "unveil" or "seccomp", help prevent system compromise (e.g. access to *all files*) if an application, like Forgejo, gets compromised. Those require careful engineering, large-scale testing and distribution. (160h) (Disclaimer: I have explored Landlock before myself, but haven't had the concentration to make it "workable".)

I agree with all of @mfenniak's proposals.

Mine:

  • Improve accessibility (keyboard navigation, hierarchy, proper labelling, scaling); 120h (a wild guess, impossible to estimate without research and proper scope, but easy to scale up and down once the foundation is in place)
  • Improve usability: better affordances for links, buttons, better spacing, improved visual hierarchy; 80-100h (again a wild guess)
  • Automated analysis of test reports and similar information in Forgejo Actions (no estimate because it's so broad; can be a little as a week)

To me, accessibility is the most important one because it also helps with testing.

@n0toose: systemd-analyze security might be a first step that requires less work. Continuous QA is the hard part.

I agree with all of @mfenniak's proposals. Mine: * Improve accessibility (keyboard navigation, hierarchy, proper labelling, scaling); 120h (a wild guess, impossible to estimate without research and proper scope, but easy to scale up and down once the foundation is in place) * Improve usability: better affordances for links, buttons, better spacing, improved visual hierarchy; 80-100h (again a wild guess) * Automated analysis of test reports and similar information in Forgejo Actions (no estimate because it's so broad; can be a little as a week) To me, accessibility is the most important one because it also helps with testing. @n0toose: `systemd-analyze security` might be a first step that requires less work. Continuous QA is the hard part.
Author
Member
Copy link
  • Scoped access tokens (i.e. repository-wide tokens) - "Tokens" are passwords that can be easily revoked. Users that push to Git repositories on Forgejo often have to rely on creating new "service" accounts so as to reduce the attack surface of their organization, which is rather counterintuitive and might increase the attack surface (e.g. service accounts' credentials might not be rotated or forgotten about entirely).

Relevant issue: forgejo/forgejo#4992 - This was inspired due to a user support question on a random Matrix chat where someone asked a related question about Codeberg and Forgejo, but we have received many similar inquiries in the past. I find this relevant towards making Forgejo more "production-ready".

- Scoped access tokens (i.e. repository-wide tokens) - "Tokens" are passwords that can be easily revoked. Users that push to Git repositories on Forgejo often have to rely on creating new "service" accounts so as to reduce the attack surface of their organization, which is rather counterintuitive and might increase the attack surface (e.g. service accounts' credentials might not be rotated or forgotten about entirely). Relevant issue: https://codeberg.org/forgejo/forgejo/issues/4992 - This was inspired due to a user support question on a random Matrix chat where someone asked a related question about Codeberg and Forgejo, but we have received many similar inquiries in the past. I find this relevant towards making Forgejo more "production-ready".

My top feature requests from out of my head

  • Private issues/pull requests: this would allow to work on security issues not via sending e-mails in exchange, but with all the advantages of the existing issue tracker, possibly even for pull requests, could also be helpful for moderation if issues can be made private, too. forgejo/forgejo#4944 forgejo/design#2
  • Move issues from one repository issue tracker to another forgejo/forgejo#1280

But, I can't estimate needed hours for that. Both still need design work and proper implementation with security by design.

My top feature requests from out of my head - Private issues/pull requests: this would allow to work on security issues not via sending e-mails in exchange, but with all the advantages of the existing issue tracker, possibly even for pull requests, could also be helpful for moderation if issues can be made private, too. https://codeberg.org/forgejo/forgejo/issues/4944 https://codeberg.org/forgejo/design/issues/2 - Move issues from one repository issue tracker to another https://codeberg.org/forgejo/forgejo/issues/1280 But, I can't estimate needed hours for that. Both still need design work and proper implementation with security by design.
Author
Member
Copy link

REUSE software support - The introduction of the standard put forward by the Free Software Foundation Europe would mean alignment with standards including for software and hardware supply chains, as well as SBOMs.

Relevant issue: forgejo/forgejo#2832

**REUSE software support** - The introduction of the standard put forward by the [Free Software Foundation Europe](https://fsfe.org) would mean alignment with standards including for software and hardware supply chains, as well as SBOMs. Relevant issue: https://codeberg.org/forgejo/forgejo/issues/2832

I may add one other features concerning better moderation tooling, which I found useful seeing it on GitHub:

  • Possibility to hide comments with/without reason. Currently, comments can be only deleted or edited. forgejo/forgejo#6994
I may add one other features concerning better moderation tooling, which I found useful seeing it on GitHub: - Possibility to hide comments with/without reason. Currently, comments can be only deleted or edited. forgejo/forgejo#6994

I've been asked by @gusted to list a few ideas I've been sitting on for a while now. The main premise of this is to show that git itself is plenty fast, steadily becoming faster, more efficient and feature rich with each release and that there is a lot of untapped potential with how Forgejo interacts and makes use of git. Both performance and UX wise. There are also many smaller (git related) things that did not make it into this list.

  • Modify various API routes and frontend views that are mainly git operations to use relative pagination (previous, next) instead of absolute pagination (page 2 of 5 total), as that matches the data model of git better and gets rid of a bunch of redundant, expensive and hard to cache git invocations.
  • Rework the last commit loader when browsing a repository. Forgejo has two vastly different implementations for this one task with two very different performance characteristics. In the end, both are significantly slower than they need to be and in larger repositories you often end up calling both, wasting even more compute. There are better ways to archive this in git nowadays, especially with bloom filters enabled.
  • Inconsistent handling of pathspec. This can cause git to traverse the entirety of a repository for a single request. It would be interesting to expose this extensive git functionality on purpose in the UI as new purpose-built frontend views with proper documentation. Either way, the existing routes should consistently escape pathspec.
I've been asked by @gusted to list a few ideas I've been sitting on for a while now. The main premise of this is to show that git itself is plenty fast, steadily becoming faster, more efficient and feature rich with each release and that there is a lot of untapped potential with how Forgejo interacts and makes use of git. Both performance and UX wise. There are also many smaller (git related) things that did not make it into this list. - Modify various API routes and frontend views that are mainly git operations to use relative pagination (_previous_, _next_) instead of absolute pagination (_page 2 of 5 total_), as that matches the data model of git better and gets rid of a bunch of redundant, expensive and hard to cache git invocations. - Rework the last commit loader when browsing a repository. Forgejo has two vastly different implementations for this one task with two very different performance characteristics. In the end, both are significantly slower than they need to be and in larger repositories you often end up calling both, wasting even more compute. There are better ways to archive this in git nowadays, especially with bloom filters enabled. - Inconsistent handling of [pathspec](https://git-scm.com/docs/gitglossary#def_pathspec). This can cause git to traverse the entirety of a repository for a single request. It would be interesting to expose this extensive git functionality on purpose in the UI as new purpose-built frontend views with proper documentation. Either way, the existing routes should consistently _escape_ pathspec.
Member
Copy link

Since NLnet funding for ActivityPub/ForgeFed work is on hold until their next funding round, it could be worthwhile to propose continued work to this public institution.

We still have a number of open PRs, and milestone work items to complete. Perhaps having funding from a transparent organization will also allow for more interaction/participation from Codeberg e.V. maintainers.

In addition to resolving the currently open PRs, we have plans to work on:

  • federated issues
    • federated issue comments
    • federated issue status
  • federated PRs
    • federated review comments
    • federated review threads
    • federated code quotes
    • federated review status
  • ForgeFed access control
    • integrating Grants with the existing Forgejo access control concepts
    • moderation tools

The above list is a non-exhaustive summary of the longer plan submitted to NLnet.

Since NLnet funding for ActivityPub/ForgeFed work is on hold until their next funding round, it could be worthwhile to propose continued work to this public institution. We still have a number of open PRs, and milestone work items to complete. Perhaps having funding from a transparent organization will also allow for more interaction/participation from Codeberg e.V. maintainers. In addition to resolving the currently open PRs, we have plans to work on: - federated issues - federated issue comments - federated issue status - federated PRs - federated review comments - federated review threads - federated code quotes - federated review status - ForgeFed access control - integrating `Grants` with the existing Forgejo access control concepts - moderation tools The above list is a non-exhaustive summary of the longer [plan submitted to NLnet](https://codeberg.org/forgejo/sustainability/src/branch/main/2025/2025-08-01-nlnet-ngi0-commons-federation/2026-01-15-message-to-nlnet.md).

From my point of view, federation is probably the main long-term feature that could benefit from any funding opportunity; but I'm not really up to date with what is already implemented or in progress (so that I can propose tasks). Nevertheless, besides what @0xllx0 already added I would like to include some features that I think will be nice if they could be available sooner than others which are more complex:

  • federated repository watch
  • federated issue/pull subscribe
  • federated explore/search for users, organizations or repositories

Also, since moderation was mentioned few times, I would like to include the following proposals:

  • Introduce a moderator user role so that abuse reports could be reviewed and handled not only by admins but also by this new category of users;
    Discussions regarding user roles already happened 2 years ago (when abusive content reporting was not yet implemented) in forgejo/forgejo#1887 but without a clear consensus, I would say. This can be something quite big and complex but I think it would worth revisiting the topic and maybe start with some smaller steps (e.g. first include just a super-admin role - as the equivalent of IsAdmin field - without defining and mapping all the permissions, since the super-admin will always have all of them).
  • Implement audit logging for abuse reports (who did what and when);
  • Implement some UI for being able to see an overview with the abuse reports submitted by yourself;
From my point of view, federation is probably the main long-term feature that could benefit from any funding opportunity; but I'm not really up to date with what is already implemented or in progress (so that I can propose tasks). Nevertheless, besides what @0xllx0 already added I would like to include some features that I think will be nice if they could be available sooner than others which are more complex: - federated repository watch - federated issue/pull subscribe - federated explore/search for users, organizations or repositories --- Also, since moderation was mentioned few times, I would like to include the following proposals: - Introduce a _moderator_ user role so that abuse reports could be reviewed and handled not only by admins but also by this new category of users; Discussions regarding user roles already happened 2 years ago (when abusive content reporting was not yet implemented) in https://codeberg.org/forgejo/forgejo/issues/1887 but without a clear consensus, I would say. This can be something quite big and complex but I think it would worth revisiting the topic and maybe start with some smaller steps (e.g. first include just a super-admin role - as the equivalent of `IsAdmin` field - without defining and mapping all the permissions, since the super-admin will always have all of them). - Implement audit logging for abuse reports (who did what and when); - Implement some UI for being able to see an overview with the abuse reports submitted by yourself;
Sign in to join this conversation.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
NLnet
2022年08月01日
NLnet grant application submitted August 2022
NLnet
2022年12月01日
NLnet grant application submitted December 2022
NLnet
2024年04月01日
NLnet grant application submitted April 2024

Archived

NLnet
2024-04-364
NLnet grant application submitted April 2025 (was "backported" by NLnet internally)
OTF
2024年05月17日
OTF grant application submitted May 2024

Archived

STF
2024年08月15日
Sovereign Tech Fund application submitted August 2024
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
7 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo/sustainability#163
Reference in a new issue
forgejo/sustainability
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?