Security reporting with a forge #448

Ryuno-Ki commented 2026年02月27日 13:55:09 +01:00

Recently, the cURL project moved from Hackerone to GitHub and back over AI slop resp. a subpar experience.

Daniel Stenberg blogged about the process and stated some requirements why Codeberg, Gitlab et al were non-choices. Feels like something Forgejo can consider:

What we want from a security reporting system

To illustrate what we are looking for, I made a little list that should show that we’re not looking for overly crazy things.

1. Incoming submissions are reports that identify security problems.
2. The reporter needs an account on the system.
3. Submissions start private; only accessible to the reporter and the curl security team
4. All submissions must be disclosed and made public once dealt with. Both correct and incorrect ones. This is important. We are Open Source. Maximum transparency is key.
5. There should be a way to discuss the problem amongst security team members, the reporter and per-report invited guests.
6. It should be possible to post security-team-only messages that the reporter and invited guests cannot see
7. For confirmed vulnerabilities, an advisory will be produced that the system could help facilitate
8. If there’s a field for CVE, make it possible to provide our own. We are after all our own CNA.
9. Closed and disclosed reports should be clearly marked as invalid/valid etc
10. Reports should have a tagging system so that they can be marked as "AI slop" or other terms for statistical and metric reasons
11. Abusive users should be possible to ban/block from this program
12. Additional (customizable) requirements for the privilege of submitting reports is appreciated (rate limit, time since account creation, etc)

E-Mail was also excluded for reasons listed there.

Recently, the cURL project moved from Hackerone to GitHub and back over AI slop resp. a subpar experience. Daniel Stenberg [blogged about the process](https://daniel.haxx.se/blog/2026/02/25/curl-security-moves-again/) and stated some requirements why Codeberg, Gitlab et al were non-choices. Feels like something Forgejo can consider: > ## What we want from a security reporting system > > To illustrate what we are looking for, I made a little list that should show that we’re not looking for overly crazy things. > > 1. Incoming submissions are reports that identify security problems. > 2. The reporter needs an account on the system. > 3. Submissions start private; only accessible to the reporter and the curl security team > 4. All submissions must be disclosed and made public once dealt with. Both correct and incorrect ones. This is important. We are Open Source. Maximum transparency is key. > 5. There should be a way to discuss the problem amongst security team members, the reporter and per-report invited guests. > 6. It should be possible to post security-team-only messages that the reporter and invited guests cannot see > 7. For confirmed vulnerabilities, an advisory will be produced that the system could help facilitate > 8. If there’s a field for CVE, make it possible to provide our own. We are after all our own CNA. > 9. Closed and disclosed reports should be clearly marked as invalid/valid etc > 10. Reports should have a tagging system so that they can be marked as "AI slop" or other terms for statistical and metric reasons > 11. Abusive users should be possible to ban/block from this program > 12. Additional (customizable) requirements for the privilege of submitting reports is appreciated (rate limit, time since account creation, etc) E-Mail was also excluded for reasons listed there.

aahlenst commented 2026年02月27日 14:16:32 +01:00

There's already a feature request: forgejo/forgejo#142. Stenberg's points have been brought up, too.

There's already a feature request: https://codeberg.org/forgejo/forgejo/issues/142. Stenberg's points have been brought up, too.

Ryuno-Ki commented 2026年02月27日 16:03:34 +01:00

Thanks. I felt the concrete implementation vision is unclear enough that I looked into the discussion repo but haven't checked the forgejo one.

Thanks. I felt the concrete implementation vision is unclear enough that I looked into the discussion repo but haven't checked the forgejo one.

cdotnow commented 2026年02月27日 20:44:43 +01:00

On a funny side:

In point 11, there is a logical error. As of now, it seems like abusive users should be possible to ban. Which basically would mean they have admin rights.

Passive form should be used.

On a more serious note: I agree. Especially with 4. Transparency indeed is key.

On a funny side: In point 11, there is a logical error. As of now, it seems like abusive users should be possible to ban. Which basically would mean they have admin rights. Passive form should be used. On a more serious note: I agree. Especially with 4. Transparency indeed is key.