Rooba
/
oss-fuzz
mirror of https://github.com/google/oss-fuzz.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update ideal_integration.md

This commit is contained in:
Kostya Serebryany 2016-11-18 15:25:28 -08:00 committed by GitHub
parent d9acfd22c4
commit 8169480754
1 changed files with 16 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/ideal_integration.md
View File

@ -10,7 +10,11 @@ simple and efficient, and will allow to catch regressions early on in the develo
The code of the [fuzz target(s)](http://libfuzzer.info/#fuzz-target) should be part of the project's source code repository. The code of the [fuzz target(s)](http://libfuzzer.info/#fuzz-target) should be part of the project's source code repository.
All fuzz targets should be easily discoverable (e.g. reside in the same directory, or follow the same naming pattern, etc). All fuzz targets should be easily discoverable (e.g. reside in the same directory, or follow the same naming pattern, etc).
This makes it easy to maintain fuzzer and minimizes breakages that can arise as source code changes over time. This makes it easy to maintain the fuzzers and minimizes breakages that can arise as source code changes over time.
Make sure to fuzz the target locally for a small period of time to ensure that
it does not crash, hang, or runs out of memory instantly.
See details at http://libfuzzer.info and http://tutorial.libfuzzer.info
Examples: Examples:
[boringssl](https://github.com/google/boringssl/tree/master/fuzz), [boringssl](https://github.com/google/boringssl/tree/master/fuzz),
@ -84,3 +88,14 @@ This will allow to have minimal OSS-Fuzz-specific configuration and thus be more
There is no point in hardcoding the exact compiler flags in the build system because they There is no point in hardcoding the exact compiler flags in the build system because they
a) may change and b) are different depending on the fuzzing target and the sanitizer being used. a) may change and b) are different depending on the fuzzing target and the sanitizer being used.
## Not a project member?
If you are the member of the project you want to fuzz, most of the steps above are simple.
However in some cases someone outside the project team may want to fuzz the code.
If so, and the project members are not interested in coopearation, the easiest is to create a
separate GitHub project with the fuzz target, corpus, dictionary, etc.
In simple cases we can even host the fuzz target in this repository
(examples: [libxml2](../targets/libxml2), [c-ares](../targets/c-ares), [expat](../targets/expat)),
but this is the pattern we **strongly discourage**
because it is harder to maintain and is not tied to the project's continuos integration testing.