* H3: Update for functions returning error codes
* Read H3 index directly from uint8_t data, not string
* remove new_str
* Fix pointer/int type confusion
* Revert h3NeighborRotations change that is not in master yet
* Fix h3NeighborRotations (again)
* wasmtime: provide OCaml packages for build
In order to build the WebAssembly spec interpreter, these packages are needed.
* wasmtime: remove ocamlbuild as a dependency
The oss-fuzz-base image is using Ubuntu 16.04.7 and the `ocaml-nox` package at this version contains `ocamlbuild`.
* tpm2-tss: update version of tpm simulator
Getting tpm simulator is failing occasionally [1].
Updating simulator version to the lastet might help it.
[1] https://oss-fuzz-build-logs.storage.googleapis.com/log-66fdad5b-1f63-4bc2-8a0e-876201912036.txt
Signed-off-by: Tadeusz Struk <tstruk@gmail.com>
* tpm2-tss: update outdated contact list
Signed-off-by: Tadeusz Struk <tstruk@gmail.com>
* tpm2-tss: add main_repo section
Signed-off-by: Tadeusz Struk <tstruk@gmail.com>
The instructions for building libclamav-only dependencies changed.
The clamav_deps collection is now used for all clamav dependencies.
A) We don't need to waste resources building dependencies used only
by clamav programs.
B) The ncurses static build seems to be failing on this image, which
is why the build is broken/needs fixing.
The JBIG2 format allows for ridiculously large images (4G x 4G
pixels!), which means that jbig2dec may use an enormous amount of
memory when it tries to decode them. OSS-fuzz currently restricts test
cases to 2.5Gbyte of memory per run, so the jbig2dec fuzzer
implemented a custom allocator to limit jbig2dec's memory usage to
1Gbyte. When the custom allocator runs out of memory jbig2dec
indicates an error, frees its resources and returns.
Limiting memory usage to 1Gbyte, below OSS-fuzz's limit of 2.5Gbyte,
eliminated the entire class of false positive OSS-fuzz issues
concerning out of memory situations. These were false positives in the
sense that a program using jbig2dec is in control of how much memory
jbig2dec uses, but the program must implement a custom jbig2dec
allocator and limit it to the desired amount of memory.
Another class of false positive OSS-fuzz issues remain; issues where
the image data still takes more than 25 seconds to process, causing an
OSS-fuzz timeout. These cases use less than 1Gbyte of memory, but
processing that amount of data may still take a long time. Since
processing time and data size are related, a program may limit the
amount of memory allotted to jbigdec's custom allocator to something
less than 1Gbyte to reduce processing time.
Running through a set of real world JBIG2 images shows that no more
than 20MByte is used to decode any of them and none take more then 25
seconds to decode on a desktop machine. To eliminate the class of
false positive OSS-fuzz timeout issues the fuzzer will now limit the
amount of memory to 32Mbyte with the hope that their processing time
will be reduced below 25 seconds.
Of course OSS-fuzz may still detect issues where jbig2dec gets caught
in an endless loop (or the processing time is long for a reason other
than data size). These are the issues we want OSS-fuzz to identify and
get fixed, since the parameters causing those timeouts are not in
control by a program using jbig2dec.
I started writing some important docs, such as overview, build_integration, and running_clusterfuzzlite. However, most important docs are still TODO.
This PR at least adds a skeleton for those docs.
Add support to helper.py for external projects for all subcommands except `download_corpora`.
External users just need to specify `build_integration_path`, `project_src_path` and `external`.
Also do a big refactor to pass a project object as part of args instead of a string containing the name of the project or its
path.
Related: #6125
This test doesn't really do diffing or affected fuzzers properly.
Nor does it check the workspace for existence of certain things, nor
does check the filesystem for proof things happened. It is still
a WIP.
Isaac Brodsky