Lines Matching +full:oss +full:- +full:fuzz

1 ---
6 permalink: /advanced-topics/ideal-integration/
7 ---
9 # Ideal integration with OSS-Fuzz
12 OSS projects have different build and test systems. We can't expect them all to
13 implement and maintain fuzz targets or integrate them with OSS-Fuzz in the same
19 [example](https://github.com/google/oss-fuzz/tree/master/projects/example/my-api-repo)
22 - TOC
24 ---
28 Every [fuzz target](http://libfuzzer.info/#fuzz-target):
29 * Is [maintained by code owners](#fuzz-target) in their RCS (Git, SVN, etc).
30 * Is [built with the rest of the tests](#build-support) - no bit rot! 
31 * Has a [seed corpus](#seed-corpus) with good [code coverage](#coverage).
33 * Is [continuously tested on the seed corpus](#regression-testing) with
37 ## Fuzz Target
39 The code of the [fuzz target(s)](http://libfuzzer.info/#fuzz-target) should be
40 part of the project's source code repository.  All fuzz targets should be easily
47 Make sure to fuzz the target locally for a small period of time to ensure that 
49 trouble, read about [what makes a good fuzz
50 target](https://github.com/google/fuzzing/blob/master/docs/good-fuzz-target.md).
52 The interface between the [fuzz target]((http://libfuzzer.info/#fuzz-target))
54 fuzz target.
57 [boringssl](https://github.com/google/boringssl/tree/master/fuzz),
59 [s2n](https://github.com/awslabs/s2n/tree/master/tests/fuzz),
60 [openssl](https://github.com/openssl/openssl/tree/master/fuzz),
69 Many different build systems exist in the open-source world. The less OSS-Fuzz
72 An ideal build integration for OSS-Fuzz looks like this:
73 * For every fuzz target `foo` in the project, there is a build rule that
77 …G_ENGINE` (env var [provided]({{ site.baseurl }}/getting-started/new-project-guide/) by OSS-Fuzz e…
87 This minimizes OSS-Fuzz-specific configuration, making your fuzzing more robust.
96 to the fuzz target as a starting point (to "seed" the mutations). The quality of
101 For better OSS-Fuzz integration,  the seed corpus should be available in
107 [boringssl](https://github.com/google/boringssl/tree/master/fuzz),
108 [openssl](https://github.com/openssl/openssl/tree/master/fuzz),
109 [nss](https://github.com/mozilla/nss-fuzzing-corpus) (corpus in a separate repo).
118 maintained alongside the fuzz target, and it must use [correct
123 For a fuzz target to be useful, it must have good coverage in the code that it
124 is testing. You can view the coverage for your fuzz targets by looking at the
125 [fuzzer stats]({{ site.baseurl }}/further-reading/clusterfuzz#fuzzer-stats)
127 }}/further-reading/clusterfuzz#coverage-reports).
130 [code coverage]({{ site.baseurl }}/advanced-topics/code-coverage) page.
133 corpora, and fixing timeouts/out-of-memory bugs in your targets.
137 Fuzz targets should be regularly tested (not necessarily fuzzed!) as a part of
138 the project's regression testing process. One way to do so is to link the fuzz
140 ([example](https://github.com/llvm-mirror/compiler-rt/tree/master/lib/fuzzer/standalone))
146 [openssl](https://github.com/openssl/openssl/blob/master/fuzz/test-corpus.c).
150 Fuzz targets should perform well, because high memory usage and/or slow
153 }}/further-reading/clusterfuzz/#performance-analyzer) for each fuzz target that
158 If you are a member of the project you want to fuzz, most of the steps above are
159 simple. However in some cases, someone outside the project team may want to fuzz
162 In such cases, we can host the fuzz targets, dictionaries, etc. in OSS-Fuzz's 
163 repository and mention them in the Dockerfile. It's not ideal, because the fuzz
166 Examples: [libxml2](https://github.com/google/oss-fuzz/tree/master/projects/libxml2),
167 [c-ares](https://github.com/google/oss-fuzz/tree/master/projects/c-ares), [expat](https://github.co…
170 bugs found by OSS-Fuzz.