mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-09-08 13:18:52 +00:00
Currently disabled but may be enabled later. Updates the existing fuzzing to use shared libraries as that's easier for meson to deal with if there is a mix of static and shared libraries on the system. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2123> |
||
---|---|---|
.. | ||
build-oss-fuzz.sh | ||
gst-discoverer.c | ||
gst-discoverer.corpus | ||
localfuzzer.c | ||
meson.build | ||
README.txt | ||
typefind.c |
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 * *.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 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 ?