Carrot disclosure: Forgejo

i appreciate the consideration, both to my comments and to the overall improvement of the policy. i've read through the new one and it's pretty good.

it's roughly the same size (+- 1 line, it seems), but is far less painful and tiring to read. though at the risk of sounding like i'm intentionally being difficult to please, i think the following should be emphasised:

If you've discovered a security vulnerability, and believe that knowledge of that vulnerability may create serious risk to users, ...

If you've discovered a security vulnerability where you do not believe that users are at serious risk, ...

these are the two most important lines in the entire document, bar none, and they point researchers in two different directions in a rather important way.

i like the introduction of rough examples of risk categorisation. it's helpful from an independent researcher pov to understand what a bug might mean to the project - it might look worrying to me, even with my context as a heavy user of forgejo, but not actually really be all too impactful in the grand scheme of things.

i think the old timeline list had the right idea. it doesn't have to have date ranges in (and probably shouldn't, because it makes it way easier to define things on a case-by-case in a place where that is very regularly going to be needed), but it provides a way for me, as a researcher, to see how you expect it to flow. because this includes dependencies and dependents in your case, this chain can be a bit more complex than reporting something to, say, a proprietary platform where they largely don't care about those auxiliaries, or a project that has up to only a handful of third-party dependencies that largely include "glibc".

• A security issue is reported to Forgejo and investigated by our team

• Affected upstream third-parties (e.g. libraries or related projects) are informed immediately after confirmation by Forgejo

• Affected downstream third-parties which work upon the source code (e.g. distributions packagers) can receive notice ahead of time

• Affected system administrators can receive advance notice of an upcoming security release via codeberg.org/forgejo/security-announcements/issues

the latter half of this was folded into a later paragraph, but i think it should come back a bit more. :)

i'm not 100% convinced that it should be a "moderation" team being dragged in when a researcher has come to the conclusion that the development team isn't sufficiently appreciating the severity of an issue. is the moderation team technical? do they work directly on triage or remediation implementation? it's introducing a party that is otherwise not privy to sensitive information, to sensitive information, for the sake of what appears to be responsibility overlap. i think you should (be able to) have confidence that the security team is capable of handling this as a collective, and represent that confidence. should john duplicatesubmitter, hackerone's premiere noise to signal ratio generator, happen upon something important thanks to fable and then decide that the forgejo team isn't moving at the correct speed, suddenly you have a bunch more people that have been included in the mix that really ... don't need to be there, ever.

finally, you have a piece that i think is really valuable to operators and should be pushed to the readme.md (as well):

It is recommended that Forgejo administrators receive advance notice of upcoming security releases by subscribing to the security-announcements repository; either watching the repository for notifications on Codeberg, or using the security-announcements RSS feed. For notifications when any Forgejo release is published, follow Forgejo's Mastodon account or Forgejo's Release RSS feed.

all told, i like the new one. with the above in mind it'd probably become one of the ones i point to when other projects of similar size ask. curl's is great but it's very big for very big reasons, this new one here is the right size for the right problem. :)