Requesting addition of AFL++ Fuzzer Engine. about clusterfuzzlite HOT 5 OPEN

Why do you want it? Adding it has a cost and there will be a cost to maintain it.

from clusterfuzzlite.

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?

from clusterfuzzlite.

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)

from clusterfuzzlite.

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.

from clusterfuzzlite.

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.

from clusterfuzzlite.