- Do not fail silently on compilation issues
- Use a static version of freetype
- Render the PDF on a bitmap, to exercise more code paths.
- I'm planning on adding more outputs (maybe in new fuzzers) for Postscript for example
- Exercise more metadata gathering functions
- Use a stream instead of a file, to speed the fuzzer up
- Allocate the PDFDoc on the stack instead of the heap
- Don't install recommended packages
Co-authored-by: Autofuzz team <security-tps@google.com>
- Check the certificate when downloading the source code archive
- Don't use Qt, since it's only used for the xpdf GUI
- Be less verbose when unpacking the xpdf source code
- Install libpng, freetype and zlib to increase coverage
- Explicitly disable multithreading
- Exercise more codepaths
Co-authored-by: Autofuzz team <security-tps@google.com>
* Added new fuzzer to xpdf.
* Updated sanitizers.
* Limit sanitizer to address as this is the only one that allows us to fuzz the pdf core parser.
* Disable logging and go further into the API.
* Added xpdf project.
* Tried linking with cxx.
* Since the executables build are not needed for the fuzzer build to succeed we can ignore the case where some test-apps are not build on the oss-fuzz platform.
* Ignore errors that dont impact the fuzzers.
* Updated the project file with language field.
Navidem