gstreamer/ci/fuzzing
2023-08-30 10:55:56 +00:00
..
build-oss-fuzz.sh gst-omx: Retire the whole package 2023-07-16 19:10:03 +00:00
gst-discoverer.c build/fuzzing: integrate fuzz targets into the build system 2022-04-07 08:17:35 +10:00
gst-discoverer.corpus build/fuzzing: integrate fuzz targets into the build system 2022-04-07 08:17:35 +10:00
localfuzzer.c ci: Port CI to the new monorepo 2021-09-24 16:21:18 -03:00
meson.build build/fuzzing: integrate fuzz targets into the build system 2022-04-07 08:17:35 +10:00
README.txt fuzzing: correct typos in README.txt 2023-08-30 10:55:56 +00:00
typefind.c build/fuzzing: integrate fuzz targets into the build system 2022-04-07 08:17:35 +10:00

Fuzzing GStreamer
=================

  This directory contains the various fuzzing targets and helper
  scripts.

* Fuzzing targets

  Fuzzing targets as small applications where we can test a specific
  element or API. The goal is to have them be as small/targeted as
  possible.

    ex: appsrc ! <some_element> ! fakesink num-buffers=<small>
    
  Not all components can be tested directly and therefore will be
  indirectly tested via other targets (ex: libgstaudio will be tested
  by targets/elements requiring it)

  Anything that can process externally-provided data should be
  covered, but there are cases where it might not make sense to use a
  fuzzer (such as most elements processing raw audio/video).

* build-oss-fuzz.sh

  This is the script executed by the oss-fuzz project.

  It builds glib, GStreamer, plugins and the fuzzing targets.

* *.c

  The fuzzing targets where the data to test will be provided to a
  function whose signature follows the LibFuzzer signature:
  https://llvm.org/docs/LibFuzzer.html

* *.corpus

  A file matching a test name that contains a list of files to use when
  starting a fuzzing run.  Providing an initial set files can speed up
  the fuzzing process significantly.

* TODO

  * Add a standalone build script

    We need to be able to build and test the fuzzing targets outside
    of the oss-fuzz infrastructure, and do that in our continuous
    integration system.

    We need:

    * A dummy fuzzing engine (given a directory, it opens all files and
      calls the fuzzing targets with the content of those files.
    * A script to be able to build those targets with that dummy engine
    * A corpus of files to test those targets with.

  * Build targets with dummy engine and run with existing tests.

  * Create pull-based variants

    Currently the existing targets are push-based only. Where
    applicable we should make pull-based variants to test the other
    code paths.

  * Add more targets

    core:
      gst_parse fuzzer ?
    base:
      ext/
        ogg
	opus
	pango
	theora
	vorbis
      gst/
        subparse
	typefind : already covered in typefind target
      gst-libs/gst/
        sdp
	other ones easily testable directly ?