- 14 Jul, 2022 1 commit
-
-
The experimental function signature is only available when `GIT_EXPERIMENTAL_SHA256` is enabled.
Edward Thomson committed
-
- 20 Jun, 2022 2 commits
-
-
Users will need to be able to specify the object id type for the given object database; add a new `git_odb_options` with that option.
Edward Thomson committed -
The git_odb_hash helper functions should not assume SHA1, and instead should be given the oid type that they're producing.
Edward Thomson committed
-
- 15 Jun, 2022 1 commit
-
-
In preparation for SHA256 support, `GIT_OID_RAWSZ` and `GIT_OID_HEXSZ` need to indicate that they're the size of _SHA1_ OIDs.
Edward Thomson committed
-
- 10 Apr, 2022 1 commit
-
-
The indexer expects raw oid data, provide it.
Edward Thomson committed
-
- 28 Jan, 2022 1 commit
-
-
Deprecate the `git_packfile_hash` function. Callers should use the new `git_packfile_name` function which provides a unique packfile name.
Edward Thomson committed
-
- 11 Nov, 2021 1 commit
-
-
Edward Thomson committed
-
- 17 Oct, 2021 1 commit
-
-
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.
Edward Thomson committed
-
- 05 Jul, 2019 3 commits
-
-
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 committed -
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 committed -
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.
Patrick Steinhardt committed
-
- 22 Feb, 2019 1 commit
-
-
Update internal usage of `git_transfer_progress` to `git_indexer_progreses`.
Edward Thomson committed
-
- 22 Jan, 2019 1 commit
-
-
Edward Thomson committed
-
- 17 Jan, 2019 1 commit
-
-
Update some missed types that were continuing to use the old `GIT_OBJ` names.
Edward Thomson committed
-
- 26 Aug, 2018 1 commit
-
-
Edward Thomson committed
-
- 03 Aug, 2018 4 commits
-
-
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 committed -
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 committed -
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.
Patrick Steinhardt committed -
This change adds support for building a fuzz target for exercising the packfile parser, as well as documentation. It also runs the fuzzers in Travis to avoid regressions.
lhchavez committed
-