blob: 5ee4b8d0d0ea0ebc5c720a3e0abd3a11df3b11ad (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
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 ?
|
