decred
Fuzz testing with oss-fuzz
Enable Fuzz testing with oss-fuzz https://github.com/google/oss-fuzz , the oss-fuzz helped to identify with ethereum DoS https://adalogics.com/blog/the-importance-of-continuity-in-fuzzing-cve-2020-28362
I have some moral/privacy issues with using a google server to find vulns. But if you want to take it up for it DM me on matrix we can try to come up with something.
https://github.com/degeri/dcrd-continuous-fuzz for current fuzzing work (I am working on moving this to LibFuzzer).
I have some moral/privacy issues with using a google server to find vulns. But if you want to take it up for it DM me on matrix we can try to come up with something.
https://github.com/degeri/dcrd-continuous-fuzz for current fuzzing work (I am working on moving this to LibFuzzer).
OK, I understand your concerns. What about the risk of something like this not being discovered ?https://twitter.com/peter_szilagyi/status/1332047468004077569?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1332047468004077569%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fadalogics.com%2Fblog%2Fthe-importance-of-continuity-in-fuzzing-cve-2020-28362
Not against fuzzing.
But very against using a centralized google service (And the accepting their rules) for fuzzing.
Not sure you have actually read the google rules. They have some restrictive policies.
eg:
Once a project is signed up for OSS-Fuzz, it is automatically subject to the 90-day disclosure deadline for newly reported bugs in our tracker. This matches industry’s best practices and improves end-user security and stability by getting patches to users faster.
While 90 day disclosure period is fine for normal software if something requires a consensus change we cant get it done in 90 days.. So then it would require some patch work and multiple fixes. We will be working on their timeline instead of our own.