gstreamer/ci/fuzzing
Matthew Waters 03ff52ee69 ci/fuzzling: fix oss-fuzz build
gst-plugins-base doesn't have a cairo option anymore.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1975>
2022-03-18 13:16:42 +11:00
..
build-oss-fuzz.sh ci/fuzzling: fix oss-fuzz build 2022-03-18 13:16:42 +11:00
gst-discoverer.c ci: Port CI to the new monorepo 2021-09-24 16:21:18 -03:00
localfuzzer.c ci: Port CI to the new monorepo 2021-09-24 16:21:18 -03:00
README.txt ci: Port CI to the new monorepo 2021-09-24 16:21:18 -03:00
typefind.c ci: Port CI to the new monorepo 2021-09-24 16:21:18 -03: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/targetted 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

* 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 continous
    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 ?