From http://www.openjpeg.org/ :
"""
OpenJPEG is an open-source JPEG 2000 codec written in C language. It has
been developed in order to promote the use of JPEG 2000, a still-image
compression standard from the Joint Photographic Experts Group (JPEG).
Since may 2015, it is officially recognized by ISO/IEC and ITU-T as a
JPEG 2000 Reference Software
"""
I submit this integration of OpenJPEG into oss-fuzz on behalf of Antonin
Descampes (@detonin), one of the project leaders. The OpenJPEG side of the
integration has already been merged into openjpeg git master per
https://github.com/uclouvain/openjpeg/issues/965 /
1a8eac6a90
* [cmark] Add cmark_markdown_to_html fuzzer
* [cmark] Use correct filename for seed corpus
* [cmark] Use upstream fuzz harness
* [cmark] Do not use $WORK for temporary files
* [cmark] Generate seed corpus from michelf/mdtest repo
* [cmark] Add @kivikakk as an auto CC
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.
* GDAL: add netCDF dependency
Note that given the way GDAL will use it
(see https://trac.osgeo.org/gdal/changeset/38914 ), we won't fuzz netCDF files
themselves and test libnetcdf itself. Instead, for the purpose of oss-fuzz,
GDAL will use as input a text file (syntax of the ncdump/ncgen utilitis)
and will convert it to a (valid) netCDF file on-the-fly. This way we test how
the GDAL netCDF driver reacts, instead of potential bug in libnetcdf itself.
* GDAL: compile libnetcdf against libhdf5_serial to enable netcdf-4 support
proj.4 is standard UNIX filter function which converts
geographic longitude and latitude coordinates into cartesian
coordinates (and vice versa), and it is a C API for software
developers to include coordinate transformation in their own
software.
See http://proj4.org/
Note: it is used by the GDAL library, already in OSS-Fuzz.
Even Rouault