As discussed in the original PR#588, it may be better to
start with empty corpus, and see what happens. Even though
i have the full corpus set to get full (80%+) coverage, it
is quite likely to result in horrible performance.
Currently, the library is built with no external
dependencies - jpeg, zlib - not too sure if it makes sense
to fuzz those indirectly. And if i can built zlib in-tree,
building jpeg in-tree will be more complicated because it
does not have CMake build system.
As you can see, more than one fuzzing target is provided.
The RawSpeedFuzzer is the most global one, it will be
able to eventually cover all the code, others are more
fine-grained, and will only be able to cover some small
portion of the code. Thus, i suppose both the performance
and the coverage may win.
I did test this locally. Both the address and the undefined
configurations work.
* RawSpeed: new project proposal.
RawSpeed is a library used for loading of raw files, produced
by cameras. Pretty much all major raw formats are supported.
Especially CR2, DNG, NEF, SRW, CRW, RW2, PEF, RAF, ...
The library is used namely by darktable, PhotoFlow, rawstudio,
etc. Old version of the library is used by the LibRaw library.
As far i'm concerned, there exists only a three alive major raw
loaders like this one - dcraw, LibRaw which is based on dcraw,
and this library, RawSpeed.
Thus, it is in quite the unique position, and i deem it to be
important part of the ecosystem. Am i right or not is for you
to tell.
* Don't need to specify fuzzing engines
We use both AFL and libFuzzer, don't need to specify this.
Roman Lebedev