- 12 Oct, 2018 2 commits
-
-
On Linux (where we run valgrind) allocate a smaller buffer, but still an insanely large size. This will cause malloc to fail but will not cause valgrind to report a likely error with a negative-sized malloc. Keep the original buffer size on non-Linux platforms: this is well-tested on them and changing it may be problematic. On macOS, for example, using the new size causes `malloc` to print a warning to stderr. (cherry picked from commit 219512e7)
Edward Thomson committed -
Simplify the names for the tests, removing the unnecessary "libgit2-clar" prefix. Make "all" the new default test run, and include the online tests by default (since HTTPS should always be enabled). For the CI tests, create an offline-only test, then the various online tests. (cherry picked from commit ce798b25)
Edward Thomson committed
-
- 05 Oct, 2018 3 commits
-
-
Carlos Martín Nieto committed
-
In case a configuration includes a key "include.path=" without any value, the generated configuration entry will have its value set to `NULL`. This is unexpected by the logic handling includes, and as soon as we try to calculate the included path we will unconditionally dereference that `NULL` pointer and thus segfault. Fix the issue by returning early in both `parse_include` and `parse_conditional_include` in case where the `file` argument is `NULL`. Add a test to avoid future regression. The issue has been found by the oss-fuzz project, issue 10810. (cherry picked from commit d06d4220)
Patrick Steinhardt committed -
While our tests in config::include create a plethora of configuration files, most of them do not get removed at the end of each test. This can cause weird interactions with tests that are being run at a later stage if these later tests try to create files or directories with the same name as any of the created configuration files. Fix the issue by unlinking all created files at the end of these tests. (cherry picked from commit bf662f7c)
Patrick Steinhardt committed
-
- 03 Oct, 2018 4 commits
-
-
The parameters of the `git_pkt_parse_line` function are quite confusing. First, there is no real indicator what the `out` parameter is actually all about, and it's not really clear what the `bufflen` parameter refers to. Reorder and rename the parameters to make this more obvious. (cherry picked from commit 0b3dfbf4)
Patrick Steinhardt committed -
There are two different buffer overflows present when parsing "ok" packets. First, we never verify whether the line already ends after "ok", but directly go ahead and also try to skip the expected space after "ok". Second, we then go ahead and use `strchr` to scan for the terminating newline character. But in case where the line isn't terminated correctly, this can overflow the line buffer. Fix the issues by using `git__prefixncmp` to check for the "ok " prefix and only checking for a trailing '\n' instead of using `memchr`. This also fixes the issue of us always requiring a trailing '\n'. Reported by oss-fuzz, issue 9749: Crash Type: Heap-buffer-overflow READ {*} Crash Address: 0x6310000389c0 Crash State: ok_pkt git_pkt_parse_line git_smart__store_refs Sanitizer: address (ASAN) (cherry picked from commit a9f1ca09)
Patrick Steinhardt committed -
We are being quite lenient when parsing "ACK" packets. First, we didn't correctly verify that we're not overrunning the provided buffer length, which we fix here by using `git__prefixncmp` instead of `git__prefixcmp`. Second, we do not verify that the actual contents make any sense at all, as we simply ignore errors when parsing the ACKs OID and any unknown status strings. This may result in a parsed packet structure with invalid contents, which is being silently passed to the caller. This is being fixed by performing proper input validation and checking of return codes. (cherry picked from commit bc349045)
Patrick Steinhardt committed -
The commits following this commit are about to introduce quite a lot of refactoring and tightening of the smart packet parser. Unfortunately, we do not yet have any tests despite our online tests that verify that our parser does not regress upon changes. This is doubly unfortunate as our online tests aren't executed by default. Add new tests that exercise the smart parsing logic directly by executing `git_pkt_parse_line`. (cherry picked from commit 365d2720)
Patrick Steinhardt committed
-
- 05 Jul, 2018 2 commits
-
-
When computing the offset and length of the delta base, we repeatedly increment the `delta` pointer without checking whether we have advanced past its end already, which can thus result in an out-of-bounds read. Fix this by repeatedly checking whether we have reached the end. Add a test which would cause Valgrind to produce an error. Reported-by: Riccardo Schirone <rschiron@redhat.com> Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
Patrick Steinhardt committed -
Our delta code was originally adapted from JGit, which itself adapted it from git itself. Due to this heritage, we inherited a bug from git.git in how we compute the delta offset, which was fixed upstream in 48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As explained by Linus: Shifting 'unsigned char' or 'unsigned short' left can result in sign extension errors, since the C integer promotion rules means that the unsigned char/short will get implicitly promoted to a signed 'int' due to the shift (or due to other operations). This normally doesn't matter, but if you shift things up sufficiently, it will now set the sign bit in 'int', and a subsequent cast to a bigger type (eg 'long' or 'unsigned long') will now sign-extend the value despite the original expression being unsigned. One example of this would be something like unsigned long size; unsigned char c; size += c << 24; where despite all the variables being unsigned, 'c << 24' ends up being a signed entity, and will get sign-extended when then doing the addition in an 'unsigned long' type. Since git uses 'unsigned char' pointers extensively, we actually have this bug in a couple of places. In our delta code, we inherited such a bogus shift when computing the offset at which the delta base is to be found. Due to the sign extension we can end up with an offset where all the bits are set. This can allow an arbitrary memory read, as the addition in `base_len < off + len` can now overflow if `off` has all its bits set. Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned integer again. Add a test with a crafted delta that would actually succeed with an out-of-bounds read in case where the cast wouldn't exist. Reported-by: Riccardo Schirone <rschiron@redhat.com> Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
Patrick Steinhardt committed
-
- 06 Jun, 2018 2 commits
-
-
The test submodule::lookup::duplicated_path, which tries to verify that we detect submodules with duplicated paths, currently relies on the gitmodules file of "submod2_target". While this file has two gitmodules with the same path, one of these gitmodules has an empty name and thus does not pass `git_submodule_name_is_valid`. Because of this, the test is in fact dependent on the iteration order in which we process the submodules. In fact the "valid" submodule comes first, the "invalid" submodule will cause the desired error. In fact the "invalid" submodule comes first, it will be skipped due to its name being invalid, and we will not see the desired error. While this works on the master branch just right due to the refactoring of our config code, where iteration order is now deterministic, this breaks on all older maintenance branches. Fix the issue by simply using `cl_git_rewritefile` to rewrite the gitmodules file. This greatly simplifies the test and also makes the intentions of it much clearer.
Patrick Steinhardt committed -
When loading submodule names, we build a map of submodule paths and their respective names. While looping over the configuration keys, we do not check though whether a submodule path was seen already. This leads to a memory leak in case we have multiple submodules with the same path, as we just overwrite the old value in the map in that case. Fix the error by verifying that the path to be added is not yet part of the string map. Git does not allow to have multiple submodules for a path anyway, so we now do the same and detect this duplication, reporting it to the user.
Patrick Steinhardt committed
-
- 30 May, 2018 11 commits
-
-
With the recent change of always resolving pkg-config libraries to their full path, we do not have to manage the LIBGIT2_LIBDIRS variable anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp, which is a CMake-style library target and can thus be resolved by CMake automatically. Remove the variable to simplify our build system a bit.
Patrick Steinhardt committed -
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Sven Strickroth committed -
Erik van Zijst committed
-
This adds the 'T' status character to git_diff_status_char() for diff entries that change type.
Erik van Zijst committed -
When we want to limit our graphwalk, we use the heuristic of checking whether the newest limiting (uninteresting) revision is newer than the oldest interesting revision. We do so by inspecting whether the first item's commit time of the user-supplied list of revisions is newer than the last added interesting revision. This is wrong though, as the user supplied list is in no way guaranteed to be sorted by increasing commit dates. This could lead us to abort the revwalk early before applying all relevant limiting revisions, outputting revisions which should in fact have been hidden. Fix the heuristic by instead checking whether _any_ of the limiting commits was made earlier than the last interesting commit. Add a test.
Patrick Steinhardt committed -
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Sven Strickroth committed -
Etienne Samson committed
-
This fixes a segfault in git_reference_owner on references returned from git_reference__read_head and git_reference_dup ones.
Etienne Samson committed -
on 32-bit systems with 64-bit file descriptor offsets enabled (added -D_FILE_OFFSET_BITS=64 when compiling the test suite)
Andreas Baumann committed -
When comparing whether a path matches a directory rule, we pass the both the path and directory name to `fnmatch` with `GIT_ATTR_FNMATCH_DIRECTORY` being set. `fnmatch` expects the pattern to contain no trailing directory '/', which is why we try to always strip patterns of trailing slashes. We do not handle that case correctly though when the pattern itself has trailing spaces, causing the match to fail. Fix the issue by stripping trailing spaces and tabs for a rule previous to checking whether the pattern is a directory pattern with a trailing '/'. This replaces the whitespace-stripping in our ignore file parsing code, which was stripping whitespaces too late. Add a test to catch future breakage.
Patrick Steinhardt committed -
When fetching into a repository which has symbolic references via the "local" transport we run into an assert. The assert is being triggered while we negotiate the packfile between the two repositories. When hiding known revisions from the packbuilder revwalk, we unconditionally hide all references of the local refdb. In case one of these references is a symbolic reference, though, this means we're trying to hide a `NULL` OID, which triggers the assert. Fix the issue by only hiding OID references from the revwalk. Add a test to catch this issue in the future.
Patrick Steinhardt committed
-
- 29 May, 2018 11 commits
-
-
Carlos Martín Nieto committed
-
Carlos Martín Nieto committed
-
When dealing with `core.proectNTFS` and `core.protectHFS` we do check against `.gitmodules` but we still have a failing test as the non-filesystem codepath does not check for it.
Carlos Martín Nieto committed -
Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
Carlos Martín Nieto committed -
We may take in names from the middle of a string so we want the caller to let us know how long the path component is that we should be checking.
Carlos Martín Nieto committed -
We want to reject these as they cause compatibility issues and can lead to git writing to files outside of the repository.
Carlos Martín Nieto committed -
These can't go into the public API yet as we don't want to introduce API or ABI changes in a security release.
Carlos Martín Nieto committed -
Given a path component it knows what to pass to the filesystem-specific functions so we're protected even from trees which try to use the 8.3 naming rules to get around us matching on the filename exactly. The logic and test strings come from the equivalent git change.
Carlos Martín Nieto committed -
Otherwise we would also admit `..\..\foo\bar` as a valid path and fail to protect Windows users. Ideally we would check for both separators without the need for the copied string, but this'll get us over the RCE.
Carlos Martín Nieto committed -
If the we decide that the "name" of the submodule (i.e. its path inside `.git/modules/`) is trying to escape that directory or otherwise trick us, we ignore the configuration for that submodule. This leaves us with a half-configured submodule when looking it up by path, but it's the same result as if the configuration really were missing. The name check is potentially more strict than it needs to be, but it lets us re-use the check we're doing for the checkout. The function that encapsulates this logic is ready to be exported but we don't want to do that in a security release so it remains internal for now.
Carlos Martín Nieto committed -
We should pretend such submdules do not exist as it can lead to RCE.
Carlos Martín Nieto committed
-
- 23 Mar, 2018 2 commits
-
-
In commit 7ec7aa4a (odb: assert on logic errors when writing objects, 2018-02-01), the check for whether we are trying to overflowing the fake stream buffer was changed from returning an error to raising an assert. The conversion forgot though that the logic around `assert`s are basically inverted. Previously, if the statement stream->written + len > steram->size evaluated to true, we would return a `-1`. Now we are asserting that this statement is true, and in case it is not we will raise an error. So the conversion to the `assert` in fact changed the behaviour to the complete opposite intention. Fix the assert by inverting its condition again and add a regression test.
Patrick Steinhardt committed -
Our mempack ODB backend has no test coverage at all right now. Add a simple test suite to at least have some coverage of the most basic operations on the ODB.
Patrick Steinhardt committed
-
- 20 Mar, 2018 1 commit
-
-
Update the settings to use a specific read-only token for accessing our test repositories in Bitbucket.
Edward Thomson committed
-
- 19 Mar, 2018 2 commits
-
-
Edward Thomson committed
-
Steven King Jr committed
-