forgejo/forgejo

Fork 669

[FEAT] Secure reporting of security issues #142

New issue

Open

opened 2022-12-19 10:49:22 +01:00 by caesar · 18 comments

caesar commented

2022-12-19 10:49:22 +01:00

Member

Feature Description

I'd love it if reporting of security issues was built into Forgejo. It would really reduce the friction from reporting responsibly, which at present requires following a completely different (and harder) workflow than disclosing publicly.

I believe no forge currently has this functionality, and as @gapodo mentioned, handling of security issues is often a weak point in FOSS communities. Forgejo should enable best practicies in handling security reports without placing excessive burden (such as managing GPG keys and sending encrypted email) on either the reporter or the maintainer.

Implementation Ideas

I believe we should implement issue "categories". This would be useful for various already-proposed features, including

Discussions, like Github (#410)
Non-issue comments (#125)
More generally, we can think about better paradigms for an issue tracker that don't just lump everything together, contributing to maintainer burn-out. For example, different tracker pages for "feature requests" and "bugs".

If we implemented issue categories, creating a "security" category would be a first step to this. In addition:

The security category must be hidden except to repo "owners" (or designated teams).
Ideally, issues in the security category should be encrypted. How this should be done will need careful consideration as encyption is always a trade-off of security vs ease of use. At least on the reporting side, ease of use is vital to ensure security issues are reported appropriately.

## Feature Description I'd love it if reporting of security issues was built into Forgejo. It would really reduce the friction from reporting responsibly, which at present requires following a completely different (and harder) workflow than disclosing publicly. I believe no forge currently has this functionality, and as @gapodo mentioned, handling of security issues is often a weak point in FOSS communities. *Forgejo should enable best practicies in handling security reports* without placing excessive burden (such as managing GPG keys and sending encrypted email) on either the reporter or the maintainer. ## Implementation Ideas I believe we should implement issue "categories". This would be useful for various already-proposed features, including - Discussions, like Github (#410) - Non-issue comments (#125) - More generally, we can think about better paradigms for an issue tracker that don't just lump everything together, contributing to maintainer burn-out. For example, different tracker pages for "feature requests" and "bugs". If we implemented issue categories, creating a "security" category would be a first step to this. In addition: - The security category *must be hidden* except to repo "owners" (or designated teams). - Ideally, issues in the security category should be encrypted. How this should be done will need careful consideration as encyption is always a trade-off of security vs ease of use. At least on the reporting side, ease of use is vital to ensure security issues are reported appropriately.

👍 16

caesar added the

enhancement/feature

forgejo/security

labels

2022-12-19 10:50:07 +01:00

gapodo commented

2022-12-19 18:37:50 +01:00

Contributor

The security category must be hidden except to repo "owners" (or designated teams).

I'd extend this with "the issue should be open to the reporter", if you need internal handling do it in a 2nd issue, but allow the reporter to a) get feedback (and potentially help you by giving additional answers / clarifying) and b) potentially add to / improve the report when they find out more...

Else I'm all for it...

Re Encryption, this is always a bit hairy as the server will always have to have the key somewhere (unless we use a public key and the security team needs to use it to decrypt, which would be an absolute mess if we want the backchannel).

I'd at least like to have the option to enforce 2fa for being in the team (reporting should not require 2fa, as it would once again increase the burden to submission)

> The security category must be hidden except to repo "owners" (or designated teams). I'd extend this with "the issue should be open to the reporter", if you need internal handling do it in a 2nd issue, but allow the reporter to a) get feedback (and potentially help you by giving additional answers / clarifying) and b) potentially add to / improve the report when they find out more... Else I'm all for it... Re Encryption, this is always a bit hairy as the server will always have to have the key somewhere (unless we use a public key and the security team needs to use it to decrypt, which would be an absolute mess if we want the backchannel). I'd at least like to have the option to enforce 2fa for being in the team (reporting should not require 2fa, as it would once again increase the burden to submission)

👍 3

Ryuno-Ki commented

2023-03-21 12:14:11 +01:00

Today I had the shower thought, whether something like SecureDrop could be hosted alongside Forgejo to accept secuirty disclosures.

Today I had the shower thought, whether something like [SecureDrop](https://docs.securedrop.org/en/stable/) could be hosted alongside Forgejo to accept secuirty disclosures.

earl-warren added the

User research - Security

label

2023-10-25 14:02:41 +02:00

fnetX referenced this issue from forgejo/design

2024-07-21 16:16:30 +02:00

Private issues #2

caesar commented

2024-07-21 16:35:17 +02:00

Author

Member

I believe no forge currently has this functionality

GitHub supports this now and may be worth looking at for inspiration.

> I believe no forge currently has this functionality GitHub [supports this now](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) and may be worth looking at for inspiration.

fnetX referenced this issue from a commit

2024-07-21 16:46:47 +02:00

Bootstrap design work on private issues

fnetX referenced this issue

2024-09-16 14:14:36 +02:00

feat: Confidential issues #5336

pat-s referenced this issue

2025-02-07 11:04:16 +01:00

feat: add vulnerability dashboard #6831

addisoncrump commented

2025-08-11 19:07:16 +02:00

What is the current feeling on this? I would consider contributing, if I knew what the current desired outcome was. I see the references above, but it is clear to me that a security dashboard (e.g. with SBOM vulnerability scanning) is quite different to security reporting needs for a specific repo.

earl-warren commented

2025-08-11 22:59:34 +02:00

Contributor

@addisoncrump I suggest you start with contributing bug fixes before trying your hand on a new feature. There are plenty around and it will greatly help you get clarity on how the codebase is organized. What do you think?

addisoncrump commented

2025-08-11 23:07:59 +02:00

A fair suggestion. I do still want to know what the general consensus of this is, because this feature is important to me and I would like to eventually help development in this particular feature.

Gusted commented

2025-08-11 23:10:32 +02:00

Owner

Such a feature would be accepted in Forgejo, if implemented in a secure-by-design way (forgejo/design#2). There are other people interested in contributing this feature and it might be best to not have separate efforts to implement this.

Such a feature would be accepted in Forgejo, if implemented in a secure-by-design way (https://codeberg.org/forgejo/design/issues/2). There are other people interested in contributing this feature and it might be best to not have separate efforts to implement this.

addisoncrump commented

2025-08-11 23:14:05 +02:00

Certainly. Who else is interested? I will look into contributing to bug/confirmed+good-first-issue for now to get my hands dirty and will swing back to this when I'm more familiar.

earl-warren commented

2025-08-11 23:25:18 +02:00

Contributor

A word of advice: this is one of the most difficult feature to implement. Be prepared for a long run. I'm not trying to discourage you, this can be a very exciting adventure.

👍 1

thisismissem commented

2025-08-12 21:53:56 +02:00

I'm one of the champions of the Nivenly Fediverse Security Fund, and we've noticed that a significant number of codeberg/forgejo-hosted projects don't have any security vulnerability responsible disclosure process in place, so I'd definitely like to see this.

Maybe this is something NLNet would also be interested in sponsoring the work on, since they do care about security, and this will be a major blocker for existing open-source projects with large user-bases moving from GitHub to forgejo/codeberg.

I'm one of the champions of the [Nivenly Fediverse Security Fund](https://nivenly.org/docs/programs/fediverse-security-fund/), and we've noticed that a significant number of codeberg/forgejo-hosted projects don't have any security vulnerability responsible disclosure process in place, so I'd definitely like to see this. Maybe this is something NLNet would also be interested in sponsoring the work on, since they do care about security, and this will be a major blocker for existing open-source projects with large user-bases moving from GitHub to forgejo/codeberg.

earl-warren commented

2025-08-12 22:35:31 +02:00

Contributor

and this will be a major blocker for existing open-source projects with large user-bases moving from GitHub to forgejo/codeberg.

Do you have a specific example in mind?

As a member of the Forgejo security team, the vast majority of the time is spent on analyzing and fixing vulnerabilities. I would welcome dedicated tooling to reduce the overhead of setting up secure communication channels and a private infrastructure for developing fixes under embargo. But in the case of a project like Forgejo this is a very small fraction of the effort and would certainly not be a blocker. In the case of larger projects the ratio is likely similar and the fraction dedicated to the tooling is probably even smaller.

Am I missing something?

> and this will be a major blocker for existing open-source projects with large user-bases moving from GitHub to forgejo/codeberg. Do you have a specific example in mind? As a member of the Forgejo security team, the vast majority of the time is spent on analyzing and fixing vulnerabilities. I would welcome dedicated tooling to reduce the overhead of setting up secure communication channels and a private infrastructure for developing fixes under embargo. But in the case of a project like Forgejo this is a very small fraction of the effort and would certainly not be a blocker. In the case of larger projects the ratio is likely similar and the fraction dedicated to the tooling is probably even smaller. Am I missing something?

thisismissem commented

2025-08-12 22:57:43 +02:00

@earl-warren so take a project like Mastodon or Node.js that have a dedicated tab for Security that helps steer people in the right direction (it's just rendering security.md in the repo on a separate page, and if that file doesn't exist, helps guide them to create that)

Just having that information and guiding page helps, then from there issues that are only visible to repo owners + reporter would be the next step. Perhaps that form could have a specific structure to have a common structure between all security vulnerability reports.

We don't necessarily need to start with private pull requests, or anything like that, just giving people the tools to say "here's how to contact us for security things" it could even just trigger an email with the users' email address in reply-to, rather than full fledged issues UI.

@earl-warren so take a project like [Mastodon](https://github.com/mastodon/mastodon/security) or [Node.js](https://github.com/nodejs/node/security) that have a dedicated tab for Security that helps steer people in the right direction (it's just rendering `security.md` in the repo on a separate page, and if that file doesn't exist, helps guide them to create that) Just having that information and guiding page helps, then from there issues that are only visible to repo owners + reporter would be the next step. Perhaps that form could have a specific structure to have a common structure between all security vulnerability reports. We don't necessarily need to start with private pull requests, or anything like that, just giving people the tools to say "here's how to contact us for security things" it could even just trigger an email with the users' email address in reply-to, rather than full fledged issues UI.

earl-warren commented

2025-08-12 23:51:49 +02:00

Contributor

Is this the major blocker you mentioned above?

thisismissem commented

2025-08-13 00:01:28 +02:00

Ideally, I think projects would want the private issues between reporter and team, but doing it via email in the short term could work too. The main thing is having a way to coordinate information disclosure, without that, that would be a blocker.

But just surfacing security information clearly would be a very good first step.

thisismissem referenced this issue from silverpill/mitra

2025-08-13 01:59:27 +02:00

Responsible disclosure policy for security vulnerabilities? #164

Gusted commented

2025-08-13 03:58:32 +02:00

Owner

@addisoncrump wrote in #142 (comment):

Certainly. Who else is interested?

@ngortheone expressed interest in this, and IIRC some Fedora people also expressed interest into this (gentle CC @jednorozec). It would be best if implementing this feature could be collaborated, I invite you to join the Forgejo developer matrix room. There's also forgejo/design#2 that contains design choices for private issues.

@addisoncrump wrote in https://codeberg.org/forgejo/forgejo/issues/142#issuecomment-6242788: > Certainly. Who else is interested? @ngortheone expressed interest in this, and IIRC some Fedora people also expressed interest into this (gentle CC @jednorozec). It would be best if implementing this feature could be collaborated, I invite you to join the [Forgejo developer matrix room](https://matrix.to/#/#forgejo-development:matrix.org). There's also https://codeberg.org/forgejo/design/issues/2 that contains design choices for private issues.

jednorozec commented

2025-10-20 09:54:36 +02:00

Hi everyone, as we’re slowly but surely rolling out Forgejo in the Fedora Project, private issues are becoming a priority. You can track our work in this epic.
We plan to implement a solution based on the recommendations in the design ticket. Expect a bit more activity around this in the coming months.

Hi everyone, as we’re slowly but surely rolling out Forgejo in the Fedora Project, private issues are becoming a priority. You can track our work in this [epic](https://codeberg.org/fedora/forgejo-deployment/issues/113). We plan to implement a solution based on the recommendations in the design ticket. Expect a bit more activity around this in the coming months.

❤️ 5 🎉 3 🚀 1

MultisampledNight commented

2026-02-23 17:38:35 +01:00

(fyi since the Fedora project migrated, it's now at https://forge.fedoraproject.org/forge/forge/issues/113)

Mormegil commented

2026-02-25 10:13:11 +01:00

I think this might be interesting here: Daniel Stenberg made a list of needs the curl project has for a security reporting system: https://daniel.haxx.se/blog/2026/02/25/curl-security-moves-again/