Daniel P. Berrangé <[email protected]> writes: > Recently QEMU has received a denial of service attack on > its bug tracker in the form of 120 reports in 10 minutes, > and now repeated by another reporter in the form of 50 > reports in the same day. > > Prior to switching security disclosures to the bug tracker, > single reporters have submited 18, 22, and 114 bug reports. > > None of this is sustainable. It is an effective denial of > service attack on the project maintainers' time. Every bug > report is a TODO item added to someone's workload. > > It is time to put hard limits on how many bugs, discovered > with assitance of automated tools, we are willing to accept > in a givenm time frame. > > This patch proposal suggests > > * No more than 5 bugs per week, per reporter > * No more than 10 bugs are permitted to be open at any > time, per reporter. > > This is explicitly scoped to bugs discovered with the assistance > of automated tools. Bugs where a human puts in exclusively > personal time / effort to discover a problem are not limited. > > Signed-off-by: Daniel P. Berrangé <[email protected]> > --- > contribute/report-a-bug.md | 37 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md > index b506f9f..8fb7b0b 100644 > --- a/contribute/report-a-bug.md > +++ b/contribute/report-a-bug.md > @@ -32,6 +32,43 @@ on GitLab, taking into account the following guidance. > triage of their output to validate all findings and reproducer > scenarios prior to submitting a bug report. > > +* QEMU policy forbids the bulk filing of large numbers of > + bug disclosures that were generated with automated tools > + (AI/LLM, static analysis, fuzers). Such actions are not > + a benefit to the project, placing an unsustainable burden > + on maintainers. > + > + * **No more than 5 bug/security reports, discovered > + with assistance of automated tools, are permitted > + to be filed per week, per reporter.** > + * **No more than 10 bug/security reports, discovered > + with assistance of automated tools are permitted > + to be open at any time, per reporter.** > + * Reporters must refrain from filing any reports > + that would cause these thresholds to be exceeded > + without first obtaining explicit prior permission > + from project maintainers. > + * Reporters are **required** to respond to triage > + comments from maintainers on bugs related to > + automated tools on a timely basis. > + * If at any time, the project maintainers request > + the reporter to stop filing bug reports discovered > + with assistance of automated tools, this must be > + honoured. > + > + Ignoring any of the above rules may lead to the bugs being > + mass closed without further triage, even if valid reports. > + In cases where the filing limits are grossly exceeded, > + the reporter's GitLab account may be reported for abuse > + (spam), potentially leading to termination. > + > + If intending to file large numbers of bug disclosures > + in aggregate, reporters are expected to invest their > + time in writing patches, providing the patches for > + review, and then further responding to feedback and > + iterating on the patches until a maintainer accepts > + them for it. > + > * Reproduce the problem directly with a QEMU command-line. Avoid > frontends and management stacks, to ensure that the bug is in > QEMU itself and not in a frontend and make it easier for
It comes across as quite a draconian limit but to be honest after a 6 months of dealing with this flood I'm less inclined to be polite about it: Reviewed-by: Alex Bennée <[email protected]> -- Alex Bennée Virtualisation Tech Lead @ Linaro
