|
b43567d6
|
2022-07-13T22:25:11
|
|
sha256: indirection for experimental functions
The experimental function signature is only available when
`GIT_EXPERIMENTAL_SHA256` is enabled.
|
|
|
3eba9181
|
2022-01-26T13:02:49
|
|
odb: add git_odb_options
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.
|
|
|
8444b6dc
|
2022-01-26T13:07:28
|
|
odb_hash*: accept the oid type to hash into
The git_odb_hash helper functions should not assume SHA1, and instead
should be given the oid type that they're producing.
|
|
|
3fbf580c
|
2022-01-23T09:47:01
|
|
oid: give oids a type
`git_oid`s now have a type, and we require the oid type when creating
the object id from creation functions.
|
|
|
dbc4ac1c
|
2022-01-22T23:10:03
|
|
oid: `GIT_OID_*SZ` is now `GIT_OID_SHA1_*SIZE`
In preparation for SHA256 support, `GIT_OID_RAWSZ` and `GIT_OID_HEXSZ`
need to indicate that they're the size of _SHA1_ OIDs.
|
|
|
f8821405
|
2022-01-27T15:19:09
|
|
fuzzer: use raw oid data
The indexer expects raw oid data, provide it.
|
|
33b1d3fd
|
2022-04-05T13:10:33
|
|
[midx] Fix an undefined behavior (left-shift signed overflow)
There was a missing check to ensure that the `off64_t` (which is a
signed value) didn't overflow when parsing it from the midx file. This
shouldn't have huge repercusions since the parsed value is immediately
validated afterwards, but then again, there is no such thing as "benign"
undefined behavior.
This change makes all the bitwise arithmetic happen with unsigned types
and is only casted to `off64_t` until the very end.
Thanks to Taotao Gu for finding and reporting this!
|
|
|
5fcfada5
|
2021-11-15T07:45:16
|
|
cmake: document CMakeLists.txt hierarchy
|
|
|
70d9bfa4
|
2022-01-22T17:34:36
|
|
packbuilder: use the packfile name instead of hash
Deprecate the `git_packfile_hash` function. Callers should use the new
`git_packfile_name` function which provides a unique packfile name.
|
|
|
395b3dc4
|
2021-11-11T22:10:51
|
|
cmake: refactor global variables
Update the global variables `LIBGIT2_OBJECTS` to
`LIBGIT2_DEPENDENCY_OBJECTS` for clarity and consistency.
|
|
|
2374ba8d
|
2021-11-11T17:15:47
|
|
fuzzers: declare static functions as static
|
|
|
489aec44
|
2021-11-11T12:33:14
|
|
fuzzers: declare standalone functions
|
|
|
4d2a6839
|
2021-11-06T16:38:57
|
|
cmake: move fuzzer args to the fuzzer's cmake
|
|
95117d47
|
2021-10-31T09:45:46
|
|
path: separate git-specific path functions from util
Introduce `git_fs_path`, which operates on generic filesystem paths.
`git_path` will be kept for only git-specific path functionality (for
example, checking for `.git` in a path).
|
|
f66e7f36
|
2021-10-28T10:25:09
|
|
libgit2_clar is now libgit2_tests
in #6083 the test runner was renamed to libgit2_tests,
but not all references to the old name were updated.
this change changes all of them to use the new name.
|
|
|
52693ab4
|
2021-09-26T23:11:13
|
|
cmake: stylistic refactoring
Ensure that we always use lowercase function names, and that we do not
have spaces preceding open parentheses, for consistency.
|
|
|
4e14d4c6
|
2021-09-26T22:06:49
|
|
cmake: BUILD_CLAR is now BUILD_TESTS
Nobody knows what CLAR is. The test building option should be
`BUILD_TESTS`.
|
|
|
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.
|
|
|
f0a09160
|
2021-10-02T13:50:12
|
|
fuzzers: use updated hash functions
|
|
|
25b75cd9
|
2021-03-10T07:06:15
|
|
commit-graph: Create `git_commit_graph` as an abstraction for the file
This change does a medium-size refactor of the git_commit_graph_file and
the interaction with the ODB. Now instead of the ODB owning a direct
reference to the git_commit_graph_file, there will be an intermediate
git_commit_graph. The main advantage of that is that now end users can
explicitly set a git_commit_graph that is eagerly checked for errors,
while still being able to lazily use the commit-graph in a regular ODB,
if the file is present.
|
|
|
3fd57a75
|
2021-01-04T18:22:43
|
|
commit-graph: Introduce a parser for commit-graph files
This change is the first in a series to add support for git's
commit-graph. This should speed up commit graph traversals by avoiding
object parsing and allowing some operations to terminate earlier.
Part of: #5757
|
|
|
1f32ed25
|
2021-01-04T19:33:48
|
|
commit-graph: Support lookups of entries in a commit-graph
This change introduces `git_commit_graph_entry_find()` and
`git_commit_graph_entry_parent()`. These two functions allow a much
faster lookup of commits by ID, since the ODB does not need to be
consulted, the commit object does not need to be inflated, and the
contents of the commit object do not need to be parsed.
Part of: #5757
|
|
|
005e7715
|
2020-02-23T22:28:52
|
|
multipack: Introduce a parser for multi-pack-index files
This change is the first in a series to add support for git's
multi-pack-index. This should speed up large repositories significantly.
Part of: #5399
|
|
92e011a7
|
2019-10-15T16:22:35
|
|
fuzzers: add a new fuzzer for patch parsing
I was looking at this code anyway because the sr.ht people nerdsniped
me, and it gave me that "I should fuzz this" feeling. So have a fuzzer!
|
|
071750a3
|
2019-08-15T14:18:26
|
|
cmake: move _WIN32_WINNT definitions to root
|
|
|
75cc755f
|
2019-07-29T18:05:35
|
|
cmake: fix _WIN32_WINNT for MinGW
|
|
82b1d1da
|
2019-07-21T12:25:10
|
|
Merge pull request #5141 from pks-t/pks/azure-drop-powershell
azure: drop powershell
|
|
|
ecd4f97b
|
2019-07-20T21:15:47
|
|
fuzzer: use futils instead of fileops
|
|
|
e54343a4
|
2019-06-29T09:17:32
|
|
fileops: rename to "futils.h" to match function signatures
Our file utils functions all have a "futils" prefix, e.g.
`git_futils_touch`. One would thus naturally guess that their
definitions and implementation would live in files "futils.h" and
"futils.c", respectively, but in fact they live in "fileops.h".
Rename the files to match expectations.
|
|
|
86ecd600
|
2019-06-28T15:11:27
|
|
fuzzers: provide test targets
Instead of having to find the fuzzer executables in our Azure test
scripts, provide test targets for each of our fuzzers that will
run them with the correct paths.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
69055813
|
2019-06-28T10:50:01
|
|
fuzzers: make printf formatters cross-platform compatible
The `printf` formatters in our standalone fuzzing driver are currently
using the "%m" specifier, which is a GNU extension that prints the error
message for the error code in `errno`. As we're using libgit2 functions
in both cases anyway, let's just use `git_error_last` instead to make
this valid on all platforms.
|
|
|
48d56328
|
2019-06-28T10:47:37
|
|
fuzzers: implement `mkdtemp` alternative for Win32
The `mkdtemp` function is not available on Windows, so our download_refs
fuzzer will fail to compile on Windows. Provide an alternative
implementation to fix it.
|
|
|
d3a440ca
|
2019-01-13T10:50:13
|
|
fuzzers: use system includes
Use the system includes (defined by libgit2) as the fuzzer includes.
The fuzzers link against internal libgit2 API and therefore need to have
the full include path that libgit2 uses.
|
|
|
a1ef995d
|
2019-02-21T10:33:30
|
|
indexer: use git_indexer_progress throughout
Update internal usage of `git_transfer_progress` to
`git_indexer_progreses`.
|
|
|
1c3daccf
|
2019-01-23T09:51:50
|
|
fuzzers: don't use deprecated types
|
|
|
115a6c50
|
2019-01-10T21:44:26
|
|
errors: remove giterr usage in fuzzers
|
|
|
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.
|
|
7615794c
|
2018-10-15T18:08:13
|
|
Merge pull request #4845 from pks-t/pks/object-fuzzer
Object parsing fuzzer
|
|
463c21e2
|
2018-10-11T13:27:06
|
|
Apply code review feedback
|
|
|
a1d5fd06
|
2018-10-11T12:46:11
|
|
fuzzers: add object parsing fuzzer
Add a simple fuzzer that exercises our object parser code. The fuzzer
is quite trivial in that it simply passes the input data directly to
`git_object__from_raw` for each of the four object types.
|
|
|
6956a954
|
2018-10-11T12:26:44
|
|
fuzzers: initialize libgit2 in standalone driver
The standalone driver for libgit2's fuzzing targets makes use of
functions from libgit2 itself. While this is totally fine to do, we need
to make sure to always have libgit2 initialized via `git_libgit2_init`
before we call out to any of these. While this happens in most cases as
we call `LLVMFuzzerInitialize`, which is provided by our fuzzers and
which right now always calls `git_libgit2_init`, one exception to this
rule is our error path when not enough arguments have been given. In
this case, we will call `git_vector_free_deep` without libgit2 having
been initialized. As we did not set up our allocation functions in that
case, this will lead to a segmentation fault.
Fix the issue by always initializing and shutting down libgit2 in the
standalone driver. Note that we cannot let this replace the
initialization in `LLVMFuzzerInitialize`, as it is required when using
the "real" fuzzers by LLVM without our standalone driver. It's no
problem to call the initialization and deinitialization functions
multiple times, though.
|
|
|
416aafd1
|
2018-10-09T02:33:03
|
|
fuzzers: Port config_file_fuzzer to the new in-memory backend
|
|
|
6d6bec0c
|
2018-08-26T11:52:21
|
|
fuzzer: update for indexer changes
|
|
|
f556dea6
|
2018-08-16T15:10:51
|
|
Add a proper write loop
|
|
|
b8d4578a
|
2018-08-14T04:01:30
|
|
Add a copyright header.
|
|
|
298f5df6
|
2018-08-14T04:01:04
|
|
Further review comments, fix the build
|
|
|
8189642d
|
2018-08-14T03:55:58
|
|
Reformat
|
|
|
bcfa762b
|
2018-08-05T03:14:56
|
|
Add a config file to the corpus
|
|
|
1a8e22e8
|
2018-07-22T23:48:53
|
|
Add a config file fuzzer
|
|
|
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.
|
|
|
5db64e2f
|
2018-07-19T14:52:02
|
|
fuzzers: convert download_refs fuzzer to C
Convert the "download_refs" fuzzer from C++ to C. Rename the source file
to have it be picked up by our build system.
|
|
|
730c0edb
|
2018-07-19T14:21:35
|
|
fuzzers: import download_refs fuzzer from oss-fuzz
This is a direct copy of the code from google/oss-fuzz, written by
Nelson Elhage (@nelhage). Note that due to the ".cc" ending, the file
will not yet be picked up by the build system. This is intended, as
currently that file is partly written in C++, requiring a conversion to
C.
|
|
|
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.
|
|
|
bf3382d5
|
2018-07-19T15:22:18
|
|
cmake: remove need to add "-fsanitize=fuzzer" flag for fuzzers
Right now, users are being instrucded to add the
"-DCMAKE_EXE_LINKER_FLAGS=-fsanitize=fuzzer" flag when they want to
build our fuzzers. This is error-prone and user unfriendly. Instead,
just add the flag to our fuzzers' build instructions so that it happens
automatically. Adjust the README accordingly.
|
|
|
07cf8b38
|
2018-07-20T09:03:10
|
|
cmake: use C90 standard for our fuzzing targets
Like all our other internal code, we want to force the use of C90 for
our fuzzers. Do so by setting the "C_STANDARD" property of our fuzzing
targets.
|
|
|
ad087303
|
2018-07-20T14:20:07
|
|
fuzzers: move readme to docs/fuzzing.md
|
|
|
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.
|