fuzzing: add fuzzers from cncf-fuzzing

[AdamKorcz]

Description

Issue reference

Moves the fuzzers to Daprs repository from cncf-fuzzing.

cc @ItalyPaleAle

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Unit tests passing
• End-to-end tests passing
• Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
• Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
• Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

[ItalyPaleAle]

@AdamKorcz this is great, thanks :) How are these being used? How can we trigger fuzz tests ourselves?

[JoshVanL]

Thanks from me as well @AdamKorcz 😄

I'm also been doing some fuzz testing with our integration tests here. I think it's definitely a good idea for us to have fuzz testing at both the unit and integration level.

As a project, I think we should be using the same underlying fuzz testing library, so we need to decide on either github.com/AdaLogics/go-fuzz-headers or github.com/google/gofuzz. The reason I picked gofuzz was that this is what Kubernetes is using upstream, which the project is already heavily dependent on anyway. Does go-fuzz-headers provide us with functionality that gofuzz cannot?

Also notice you are using a personal fork of the upstream go-fuzz-headers, is there a particular reason for that @AdamKorcz? As a project, I don't think we should be relying on personal projects- particularly forks unless there is good reason for it.

[AdamKorcz]

I'm also been doing some fuzz testing with our integration tests

That is great!

Does go-fuzz-headers provide us with functionality that gofuzz cannot?

I have not used gofuzz extensively. When I tried it (a couple of years ago) I found it to be ineffective. The project is more or less unmaintained, and I am not able to improve it. All projects here use go-fuzz-headers (along with containerd, Istio and non-CNCF projects as well): https://github.com/cncf/cncf-fuzzing/tree/main/projects.

Also notice you are using a personal fork of the upstream go-fuzz-headers, is there a particular reason for that @AdamKorcz?

This is because my branch has breaking changes that I want to upstream. I should do that within 1-2 weeks.

[AdamKorcz]

How are these being used?

They are running continuously on OSS-Fuzz

How can we trigger fuzz tests ourselves?

You can run them locally with go test -fuzz=

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: -0.12% ⚠️

Comparison is base (26e8352) 64.99% compared to head (25e7db1) 64.87%.

❗ Current head 25e7db1 differs from pull request most recent head c5e0c15. Consider uploading reports for the commit c5e0c15 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6569      +/-   ##
==========================================
- Coverage   64.99%   64.87%   -0.12%     
==========================================
  Files         228      232       +4     
  Lines       20823    20646     -177     
==========================================
- Hits        13533    13395     -138     
+ Misses       6163     6135      -28     
+ Partials     1127     1116      -11     

see 77 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JoshVanL]

I have not used gofuzz extensively. When I tried it (a couple of years ago) I found it to be ineffective.

Thanks, I am very interested to know what was ineffective. This package is now heavily used in our integration tests and we should change that now to avoid a larger rewrite in future if it is not good enough.

This is because my branch has breaking changes that I want to upstream. I should do that within 1-2 weeks.

👍

[ItalyPaleAle]

Because fuzz tests can be compute-intensive, should we add a build tag so they're only run when those tests are invoked?

for example, build tag fuzztesting and then we add a command to the makefile make test-fuzz?

[mukundansundar]

+1

[AdamKorcz]

If you run the fuzzers without the -fuzz flag, then they will run as unit tests, and as such, I don't believe a dedicated make rule is necessary to run the fuzzers.

[AdamKorcz]

The failing CI tests look unrelated to me.

[dapr-bot]

This pull request has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[dapr-bot]

This pull request has been automatically closed because it has not had activity in the last 67 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!