google
There should probably be an easier way to integrate CFLite into projects integrated into OSS-Fuzz
Trying to integrate CFLite into my fork of elfutils in https://github.com/evverx/elfutils/pull/35, I basically just copied all the files from the elfutils directory to $SRC/
FROM gcr.io/oss-fuzz-base/base-builder:v1
RUN apt-get update && \
apt-get install -y pkg-config make autoconf autopoint zlib1g-dev flex bison gawk
COPY . $SRC/elfutils
RUN git clone --depth 1 https://github.com/google/oss-fuzz && \
cp oss-fuzz/projects/elfutils/build.sh $SRC/ && \
cp oss-fuzz/projects/elfutils/fuzz-dwfl-core.c $SRC/ && \
cp oss-fuzz/projects/elfutils/fuzz-dwfl-core_seed_corpus.zip $SRC/
WORKDIR elfutils
I wonder if there is an easier way to do that?
In some sense ClusterFuzzLite is simply an interface into the same codebase as CIFuzz. So maybe we can make the CIFuzz entrypoint allow users to use run modes other than code-change fuzzing. Then (because the CIFuzz entrypoint is being used) you won't need a .clusterfuzzlite directory for oss-fuzz projects. I think that would solve this issue as well as https://github.com/google/clusterfuzzlite/issues/63 What do you think?
On second thought there might be some issues with the above approach. For one, you wouldn't get build or corpus uploading.
If we can't go with something simple like the above approach, I probably won't do anything to support this. I think it would just add too much complexity to account for OSS-Fuzz projects that are in ClusterFuzzLite.
Is there any advantage to adding ClusterFuzzLite to projects already on OSS-Fuzz?
It's compatible with forks so I think it depends on whether it's important for projects to test their forks or not. systemd uses it to test stable branches (where releases consumed by some distributions are kept): https://github.com/systemd/systemd/pull/22295
If that's the only reason, maybe we should just add fork support to CIFuzz.
I think it would be great but I'm not sure how it can be implemented. For example CIFuzz always downloads the latest builds but CFLite shouldn't do that because the latest upstream builds don't match the latest "fork" builds.
I think it would be great but I'm not sure how it can be implemented. For example CIFuzz always downloads the latest builds but CFLite shouldn't do that because the latest upstream builds don't match the latest "fork" builds.
Ah makes sense.
Regarding advantages I forgot to mention that CFLite is more configurable when it comes to forks in the sense that depending on what projects need they can either download public OSS-Fuzz corpora manually (https://github.com/systemd/systemd/pull/22302) and let CFLite discover issues that haven't been caught when forks were created and backport relevant patches or rely on "stable" seed corpora to make sure forks are more or less fine in general.
Even though I still think it would be great if there was an easier way it's already possible to do it and probably it doesn't make much sense to complicate things to cover those niche use cases.