ci/fuzzing/README.txt

   1 Fuzzing GStreamer
   2 =================
   3
   4   This directory contains the various fuzzing targets and helper
   5   scripts.
   6
   7 * Fuzzing targets
   8
   9   Fuzzing targets as small applications where we can test a specific
  10   element or API. The goal is to have them be as small/targetted as
  11   possible.
  12
  13     ex: appsrc ! <some_element> ! fakesink num-buffers=<small>
  14
  15   Not all components can be tested directly and therefore will be
  16   indirectly tested via other targets (ex: libgstaudio will be tested
  17   by targets/elements requiring it)
  18
  19   Anything that can process externally-provided data should be
  20   covered, but there are cases where it might not make sense to use a
  21   fuzzer (such as most elements processing raw audio/video).
  22
  23 * build-oss-fuzz.sh
  24
  25   This is the script executed by the oss-fuzz project.
  26
  27   It builds glib, GStreamer, plugins and the fuzzing targets.
  28
  29 * *.c
  30
  31   The fuzzing targets where the data to test will be provided to a
  32   function whose signature follows the LibFuzzer signature:
  33   https://llvm.org/docs/LibFuzzer.html
  34
  35 * *.corpus
  36
  37   A file matching a test name that contains a list of files to use when
  38   starting a fuzzing run.  Providing an initial set files can speed up
  39   the fuzzing process significantly.
  40
  41 * TODO
  42
  43   * Add a standalone build script
  44
  45     We need to be able to build and test the fuzzing targets outside
  46     of the oss-fuzz infrastructure, and do that in our continous
  47     integration system.
  48
  49     We need:
  50
  51     * A dummy fuzzing engine (given a directory, it opens all files and
  52       calls the fuzzing targets with the content of those files.
  53     * A script to be able to build those targets with that dummy engine
  54     * A corpus of files to test those targets with.
  55
  56   * Build targets with dummy engine and run with existing tests.
  57
  58   * Create pull-based variants
  59
  60     Currently the existing targets are push-based only. Where
  61     applicable we should make pull-based variants to test the other
  62     code paths.
  63
  64   * Add more targets
  65
  66     core:
  67       gst_parse fuzzer ?
  68     base:
  69       ext/
  70         ogg
  71         opus
  72         pango
  73         theora
  74         vorbis
  75       gst/
  76         subparse
  77         typefind : already covered in typefind target
  78       gst-libs/gst/
  79         sdp
  80         other ones easily testable directly ?
  81
  82
  83
  84
  85
  86