You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Well, simple reason for wanting it is to find more bugs faster.
Really?? What cost?? The AFL fuzzer was displayed in your DevSecCon 2022 talk, so I know you are definitely still using it internally, why not add it to ClusterFuzzLite then and let everyone use it?
Well, simple reason for wanting it is to find more bugs faster.
I think libFuzzer is probably good enough at finding bugs. It finds most of our bugs in OSS-Fuzz so I tend to think it's a bit better.
Really?? What cost?? The AFL fuzzer was displayed in your DevSecCon 2022 talk,
Well if there is no cost to making this change you would have been able to make it yourself right? I would have to change our code to support this use case, and then fix it when it breaks etc.
Are you using ClusterFuzzLite somewhere and have found libFuzzer insufficient?
so I know you are definitely still using it internally, why not add it to ClusterFuzzLite then and let everyone use it?
We do use AFL++ in ClusterFuzz but the idea behind ClusterFuzzLite is to be lightweight even at the expense of finding more bugs. If you want to find as many bugs as possible use ClusterFuzz. I want ClusterFuzzLite to be as easy to use as possible even, and having multiple engines would confuse users and possibly burden them by having to support multiple builds (as in OSS-Fuzz there's sometimes effort required to support AFL++ in addition to libFuzzer for projects)
I just started exploring clusterfuzzlite, and a mere glance at the Lite tool showed a lot of promise (at scale) which made me ask for an addition of AFL++ thinking it is comparatively easier for the original repo owner to add fuzzers than for others to start from scratch.
Also the DevSecCon talk you presented clearly mentioned adding AFLGo in “Future Work” slide.
Hence the Ask here.
Nevertheless, I completely understand the somewhat additional work involved and if it’s too cumbersome then please don’t add AFL++ AFLGo or any other AFL-variant in future.
Also the DevSecCon talk you presented clearly mentioned adding AFLGo in “Future Work” slide.
I think I meant more the idea behind AFLGo which can target changed code more effectively.
Nevertheless, I completely understand the somewhat additional work involved and if it’s too cumbersome then please don’t add AFL++ AFLGo or any other AFL-variant in future.
Yeah, good to keep this issue open but I don't think it is likely to be added. Though we might change over to google/centipede (probably no sooner than a year from now) but this change probably wont even be visible to users.
Activity
jonathanmetzman commentedon Sep 16, 2022
Why do you want it? Adding it has a cost and there will be a cost to maintain it.
kushal89shah commentedon Sep 16, 2022
Well, simple reason for wanting it is to find more bugs faster.
Really?? What cost?? The AFL fuzzer was displayed in your DevSecCon 2022 talk, so I know you are definitely still using it internally, why not add it to ClusterFuzzLite then and let everyone use it?
jonathanmetzman commentedon Sep 16, 2022
I think libFuzzer is probably good enough at finding bugs. It finds most of our bugs in OSS-Fuzz so I tend to think it's a bit better.
Well if there is no cost to making this change you would have been able to make it yourself right? I would have to change our code to support this use case, and then fix it when it breaks etc.
Are you using ClusterFuzzLite somewhere and have found libFuzzer insufficient?
We do use AFL++ in ClusterFuzz but the idea behind ClusterFuzzLite is to be lightweight even at the expense of finding more bugs. If you want to find as many bugs as possible use ClusterFuzz. I want ClusterFuzzLite to be as easy to use as possible even, and having multiple engines would confuse users and possibly burden them by having to support multiple builds (as in OSS-Fuzz there's sometimes effort required to support AFL++ in addition to libFuzzer for projects)
kushal89shah commentedon Sep 16, 2022
I just started exploring clusterfuzzlite, and a mere glance at the Lite tool showed a lot of promise (at scale) which made me ask for an addition of AFL++ thinking it is comparatively easier for the original repo owner to add fuzzers than for others to start from scratch.
Also the DevSecCon talk you presented clearly mentioned adding AFLGo in “Future Work” slide.
Hence the Ask here.
Nevertheless, I completely understand the somewhat additional work involved and if it’s too cumbersome then please don’t add AFL++ AFLGo or any other AFL-variant in future.
jonathanmetzman commentedon Sep 16, 2022
I think I meant more the idea behind AFLGo which can target changed code more effectively.
Yeah, good to keep this issue open but I don't think it is likely to be added. Though we might change over to google/centipede (probably no sooner than a year from now) but this change probably wont even be visible to users.