fuzzers/packfile_fuzzer.c


Log

Author Commit Date CI Message
Edward Thomson f0e693b1 2021-09-07T17:53:49 str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Patrick Steinhardt 3c966fb4 2019-06-28T10:53:03 fuzzers: clean up header includes There's multiple headers included in our fuzzers that aren't required at all. Furthermore, some of them are not available on Win32, causing builds to fail. Remove them to fix this.
Patrick Steinhardt 9d43d45b 2019-06-28T12:10:51 fuzzers: use `git_buf_printf` instead of `snprintf` The `snprintf` function does not exist on Win32, it only has `_snprintf_s` available. Let's just avoid any cross-platform hassle and use our own `git_buf` functionality instead.
Patrick Steinhardt a6b2fffd 2019-06-28T11:04:21 fuzzers: use POSIX emulation layer to unlink files Use `p_unlink` instead of `unlink` to remove the generated packfiles in our packfile fuzzer. Like this, we do not have to worry about using proper includes that are known on all platforms, especially Win32.
Edward Thomson a1ef995d 2019-02-21T10:33:30 indexer: use git_indexer_progress throughout Update internal usage of `git_transfer_progress` to `git_indexer_progreses`.
Edward Thomson 115a6c50 2019-01-10T21:44:26 errors: remove giterr usage in fuzzers
Edward Thomson 83151018 2019-01-17T10:47:32 object_type: convert final internal users to new names Update some missed types that were continuing to use the old `GIT_OBJ` names.
Edward Thomson 6d6bec0c 2018-08-26T11:52:21 fuzzer: update for indexer changes
Patrick Steinhardt e38ddc90 2018-07-26T15:41:41 fuzzers: limit maximum pack object count By default, libgit2 allows up to 2^32 objects when downloading a packfile from a remote. For each of these objects, libgit2 will allocate up to two small structs, which in total adds up to quite a lot of memory. As a result, our fuzzers might run out of memory rather quick in case where they receive as input a packfile with such a huge count of objects. Limit the packfile object count to 10M objects. This is sufficiently big to still work with most largish repos (linux.git has around 6M objects as of now), but small enough to not cause the fuzzer to OOM.
Patrick Steinhardt de53972f 2018-07-20T11:07:47 fuzzers: avoid use of libgit2 internals in packfile_raw The packfile_raw fuzzer is using some internal APIs from libgit2, which makes it hard to compile it as part of the oss-fuzz project. As oss-fuzz requires us to link against the C++ FuzzingEngine library, we cannot use "-DBUILD_FUZZERS=ON" directly but instead have to first compile an object from our fuzzers and then link against the C++ library. Compiling the fuzzer objects thus requires an external invocation of CC, and we certainly don't want to do further black magic by adding libgit2's private source directory to the header include path. To fix the issue, convert the code to not use any internal APIs. Besides some headers which we have to add now, this also requires us to change to the hashing function of the ODB. Note that this will change the hashing result, as we have previously not prepended the object header to the data that is to be hashed. But this shouldn't matter in practice, as we don't care for the hash value anyway.
Patrick Steinhardt 59328ed8 2018-07-19T13:29:46 fuzzers: rename "fuzz" directory to match our style Our layout uses names like "examples" or "tests" which is why the "fuzz" directory doesn't really fit in here. Rename the directory to be called "fuzzers" instead. Furthermore, we rename the fuzzer "fuzz_packfile_raw" to "packfile_raw_fuzzer", which is also in line with the already existing fuzzer at google/oss-fuzz. While at it, rename the "packfile_raw" fuzzer to instead just be called "packfile" fuzzer.