Thanks Joe, looks good to me. I think the updated wording strikes a good balance: focusing on clear, technically justified reports rather than how they were produced.
+1 from me. Arturo On Mon, Oct 26, 2026 at 1:53 PM Joe Orton <[email protected]> wrote: > On Mon, Oct 26, 2026 at 07:57:05AM -0400, Eric Covener wrote: > > After going through a few reports this morning, maybe we can cherry > > pick some language from > > https://github.com/curl/curl/blob/master/docs/VULN-DISCLOSURE-POLICY.md: > > > > e.g. > > > > When communicating in the curl project, please explain your issues or > > improvements briefly and clearly in your own human voice. Do not > > lazily paste massive, AI-generated explanations; it is your > > responsibility to invest a few extra minutes into making your message > > digestible. The maintainers review submissions constantly, and clear > > writing reduces their daily burden and friction. > > How about this for the model scope section? Attached new diff with > Arturo's feedback plus this. > > --- 8< --- > > Every vulnerability report MUST begin with a concise, human-readable > description either: > > a) clearly identifying the aspect of this security model which is > violated by the reported bug, including any applicable > [module-specific trust boundary](#module-specific-trust-boundaries), or > > b) succinctly describing a trust boundary which is not covered by this > document, supported by references (such as the httpd documentation), > and showing how it is violated by the reported bug. > > Reports will be rejected if they invent contrived trust boundaries, or > fail to give a simple explanation of why a trust boundary is relevant. > Verbose, AI-generated reports will often fail these tests without > sufficient human review or oversight. > >
