A community-assembled project for aggregating public information regarding questions in fuzzing (and search-based testing strategies on its periphery).
See the call for contributors at the end of this document!
Fuzzing is a notoriously difficult thing to get right. Papers do and say one thing, and later efforts to reproduce or reimplement fail for one reason or another. This is rarely a function of malice; fuzzer evaluations are easy to get wrong in subtle ways, and the current paper and artifact review processes are simply not equipped to find these errors.
Similarly, there is a lot of sentiment that fuzzing is somehow "over", that there are no more questions to solve. This is somewhat true -- for the low-hanging fruit. Reviewers are starting to become more prudent, and what remains is technically and theoretically challenging. There are many questions left to solve.
Thus: fuzz.fail. This site will serve two purposes: the aggregation of online resources which further explore or refute academic papers or technical writings, and the enumeration of open questions in fuzzing.
This is not a name-and-blame site for throwing insults or engaging in baseless cynicism. This is not a site which will tolerate ad hominem or in-/out-group bias.
If you feel that you or your work is being misrepresented in any way, please open a pull request to remediate. While we won't take down valid criticisms or concerns, commentary which is abusive will be removed. If you wish to address a criticism or concern in your work or another's, please make a response publicly available and open a pull request.
See the contributor's guide for more details.
The fuzz.fail site content is licensed under CC-BY-4.0.
The fuzz.fail template is modified from Alexander Terenin's Academic Paper template, and is licensed under MIT.
Look, I don't want to be The Guy™ running this website. I think that's biased and unscientific. If anything, I want this site to serve as something to bring more scientific discourse to our domain, which has sadly gained a poor reputation due to true failings of both paper writing and review.
For this reason, I would like to mix a little democracy into this site a bit. If you are a researcher in the fuzzing domain who would like to have a say in the maintenance of this site, reach out. I will happily add maintainership access to researchers in this domain to reduce the bus factor and ensure some level of "fairness" in the site's maintenance.