Significant raise of reports

It's not much different from what we're doing, and due to the high volume we can only triage now. Syzbot reports are systematically redirected to public lists, all the stuff that doesn't represent an immediate risk of escalation but might only be used to lower some barriers (e.g. local kASLR defeats) or stuff that's outside the threat model gets the same fate, and the rest is often challenged a bit (e.g. unclear or too old version, dubious claims etc), we ask for patches and most of the time the reporters are interested in helping and they do their final share of the work, then we forward to maintainers and try to help both to get the issue fixed and merged ASAP. Many reporters are not familiar with processes, and it's the same for maintainers getting begged for the first time. It's extremely rare these days that issues are attempted to be resolved within the list (except if the maintainer is already there) as all subsystems are willing to participate to the resolution now, so the fixes are super fast, in a matter of days you can count on a single hand most of the time, which would make embargoes totally pointless anyway and even counter-productive.

> The previous approach, with the desire to have fixes available at the time of disclosure (with or without embargo/grace period for distributions) does not seem to work anymore. It doesn't encourage community collaboration, and it paves the way for rather extreme forms of freeloading.

I totally agree. And the only way it makes sense is when there's a risk of remote exploitation (e.g. RCE) but then it keeps users exposed longer, which is against the initial goal. Also this doesn't take into account the different levels of exposure of different classes of users due to different use cases. On the kernel, with a release every week, it's best to just merge and release. OpenSSL for example does one thing well, since they don't release often, they often indicate upfront that a fix is going to be released a few days later so that users can get prepared to downloading the fix and deploying. In haproxy as well we're going away from embargoes. We keep them only for critical stuff that affects common deployments with no reasonable workaround (e.g. about once a year or so), and we leave two or three days to some high profile users to deploy a fix and to distros to prepare packages. Each time it remains confusing for everyone involved and the risk of mistake remains high, so the least often the better. BTW it's well known that embargoed issues generally need two fixes: the first one which works on the reporter and the developer's machine, and the second one which fixes regressions in the field.