Run Clusterfuzz Lite

[naveensrinivasan]

LND could utilize Clusterfuzz lite https://google.github.io/clusterfuzzlite without having to worry oss-fuzz disclosure timelines.

https://google.github.io/clusterfuzzlite/

[naveensrinivasan]

Similar to #5754

[Crypt-iQ]

We might have to build the fuzz binaries w/ gofuzz such that a libFuzzer-compatible archive file is produced to make it work. I don't see go-fuzz native support in clusterfuzzlite. I think we can just have native-golang fuzzing with 1.18 instead, no special build steps

[naveensrinivasan]

I am surprised there isn't support go-fuzz. I agree go 1.18 is going to make it a lot easier.

[naveensrinivasan]

We might have to build the fuzz binaries w/ gofuzz such that a libFuzzer-compatible archive file is produced to make it work. I don't see go-fuzz native support in clusterfuzzlite. I think we can just have native-golang fuzzing with 1.18 instead, no special build steps

@Crypt-iQ Just curious is there a reason why you don't want to build libFuzzer-compatible archive file?

[Crypt-iQ]

Personally, I am not going to build a libFuzzer-build-flow with clusterfuzzlite. It doesn't make sense for me to do this if go 1.18 is pretty close. Also, is it public if it finds a bug? That would not be good.

[naveensrinivasan]

Personally, I am not going to build a libFuzzer-build-flow with clusterfuzzlite.

libfuzzer is build flag with go-build-fuzz , would you be able to share the reason as to why you don't want to run it?

The clusterfuzzlite provides an option to store the corpus and crashes into a separate repo https://google.github.io/clusterfuzzlite/running-clusterfuzzlite/github-actions/#downloading-artifacts which means it is secure and is not accessible to everyone. This repo can be private.

Also with this clusterfuzzlite, anyone can fork LND and run it to figure out a zero-day which is much easier. With the LND existing fuzzing codebase which is already there.

Wouldn't be better the team runs this? Also with the go 1.18, all of these plumbing have to be built-in and none of the existing fuzzing code can be utilized and would have to be rewritten specifically to go 1.18.

[Crypt-iQ]

You can make a pull request, but i dont have the time. Also it seems like a waste of time to make a CI action that will be removed in 1.18

[Crypt-iQ]

I take back my previous comment. Native fuzzing in 1.18 doesn't have proper code coverage, go-fuzz is better. I would review a pull implementing this.

[naveensrinivasan]

Sounds good. I will do a PR for this.

[NishantBansal2003]

looks like https://github.com/go-continuous-fuzz/go-continuous-fuzz has this covered ;)