From d89a71efd77a2933debc7e828705c641f29a56f1 Mon Sep 17 00:00:00 2001 From: Mike Aizatsky Date: Tue, 25 Oct 2016 14:34:28 -0700 Subject: [PATCH] absorbed into /README.md --- docs/overview.md | 85 ------------------------------------------------ 1 file changed, 85 deletions(-) delete mode 100644 docs/overview.md diff --git a/docs/overview.md b/docs/overview.md deleted file mode 100644 index 5752eb686..000000000 --- a/docs/overview.md +++ /dev/null @@ -1,85 +0,0 @@ -# Oss-fuzz Overview -> Applying fuzzing on a scale to common open source software. - -> *Warning: This document is a work in progress.* - -## Background - -[Fuzz testing](https://en.wikipedia.org/wiki/Fuzz_testing) is a well-known -technique for uncovering certain types of programming errors in software. -Many detectable errors (e.g. buffer overruns) have real security -implications. - -Our previous experience applying [libFuzzer](http://llvm.org/docs/LibFuzzer.html) -to do [guided in-process fuzzing of Chrome components](https://security.googleblog.com/2016/08/guided-in-process-fuzzing-of-chrome.html) -has proved very successful. - - -## Goals - -Oss-fuzz aims to make common open source software more secure by -combining modern white-box fuzzing techniques together with scalable -distributed running. - -At the first stage of the project we plan to combine -[libFuzzer](http://llvm.org/docs/LibFuzzer.html) with various `clang` -[sanitizers](https://github.com/google/sanitizers). -[ClusterFuzz](https://blog.chromium.org/2012/04/fuzzing-for-security.html) -provides distributed fuzzer execution environment and reporting. - -## Process Overview - -The following process is used for targets in oss-fuzz: - -- a target is accepted to oss-fuzz. -- oss-fuzz build server build target fuzzers regularly and submits them to - ClusterFuzz for execution. -- ClusterFuzz continuously executes target fuzzers -- when fuzzing uncovers an issue, ClusterFuzz creates an internal testcase. -- issues are automatically triaged and filed in the oss-fuzz [testcase issue - tracker](https://bugs.chromium.org/p/oss-fuzz/issues/list). - The issue is visible to *oss-fuzz engineers only*. - ([Example issue](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9).) -- if the target project has a defined process for reporting security issues, - we will follow it, otherwise we will cc library contact engineers on an issue. - The issue becomes visible to *CCed people*. -- library engineers fix the issue and land the fix upstream. -- fuzzing infrastructure automatically verifies the fix, adds a comment and - closes the issue. -- after the issue is fixed or after 90 days since reporting has passed the issue - becomes *public*. - -See [Life of a Bug](life_of_a_bug.md) for more information about handling bugs. - -## Accepting New Targets - -To be accepted to oss-fuzz, a target must be an open-source project with either -a significant user base or it has to be critical to a global IT infrastructure. - -To submit a new target to oss-fuzz: -- create a pull request and provide the following information: - * project site and details - * source code repository location - * a link to the project security issue reporting process *OR* - * an e-mail of the engineering contact person to be CCed on issue. This - has to be an established project committer e-mail (present in VCS logs) - If this is not you, the committer has to acknowledge theirself. - This e-mail will also be publicly listed in our [Projects](projects.md) - page. -- once accepted by an oss-fuzz project member, follow the [New Library Guide](new_library.md) - to write the code. - - -## Disclosure Guidelines - -Following Google's standard [disclosure policy](https://googleprojectzero.blogspot.com/2015/02/feedback-and-data-driven-updates-to.html) -oss-fuzz will adhere to following disclosure principles: - - **90-day deadline**. After notifying library authors, we will open reported - issues in 90 days, or sooner if the fix is released. - - **Weekends and holidays**. If a deadline is due to expire on a weekend or - US public holiday, the deadline will be moved to the next normal work day. - - **Grace period**. We will have a 14-day grace period. If a 90-day deadline - will expire but library engineers let us know before the deadline that a - patch is scheduled for release on a specific day within 14 days following - the deadline, the public disclosure will be delayed until the availability - of the patch.