kmx git

Commit	Date	Message
14a9a4f3	2018-11-21T11:18:46	tests: move apply_helpers functions into own compilation unit Currently, the "apply_helper" functions used for testing the apply logic are all statically defined in the "apply_helpers.h" header file. This may lead to warnings from the compiler in case where this header file is included, but not all functions it brings along are used in the compilation unit where it has been included into. Fix these potential warnings by moving the implementation into its own compilation unit "apply_helpers.c".
0e3e832d	2018-11-21T13:30:01	Merge pull request #4884 from libgit2/ethomson/index_iterator index: introduce git_index_iterator
11d33df8	2018-11-18T23:39:43	Merge branch 'tiennou/fix/logallrefupdates-always'
e226ad8f	2018-11-17T17:55:10	refs: add support for core.logAllRefUpdates=always Since we were not expecting this config entry to contain a string, we would fail as soon as its (cached) value would be accessed. Hence, provide some constants for the 4 states we use, and account for "always" when we decide to reflog changes.
646a94be	2018-11-18T23:15:56	Merge pull request #4847 from noahp/noahp/null-arg-fixes tests: 🌀 address two null argument instances
7321cff0	2018-11-15T09:17:51	Merge pull request #4713 from libgit2/ethomson/win_symlinks Support symlinks on Windows when core.symlinks=true
c358bbc5	2018-11-12T17:22:47	index: introduce git_index_iterator Provide a public git_index_iterator API that is backed by an index snapshot. This allows consumers to provide a stable iteration even while manipulating the index during iteration.
4209a512	2018-11-14T12:04:42	strntol: fix out-of-bounds reads when parsing numbers with leading sign When parsing a number, we accept a leading plus or minus sign to return a positive or negative number. When the parsed string has such a leading sign, we set up a flag indicating that the number is negative and advance the pointer to the next character in that string. This misses updating the number of bytes in the string, though, which is why the parser may later on do an out-of-bounds read. Fix the issue by correctly updating both the pointer and the number of remaining bytes. Furthermore, we need to check whether we actually have any bytes left after having advanced the pointer, as otherwise the auto-detection of the base may do an out-of-bonuds access. Add a test that detects the out-of-bound read. Note that this is not actually security critical. While there are a lot of places where the function is called, all of these places are guarded or irrelevant: - commit list: this operates on objects from the ODB, which are always NUL terminated any may thus not trigger the off-by-one OOB read. - config: the configuration is NUL terminated. - curl stream: user input is being parsed that is always NUL terminated - index: the index is read via `git_futils_readbuffer`, which always NUL terminates it. - loose objects: used to parse the length from the object's header. As we check previously that the buffer contains a NUL byte, this is safe. - rebase: this parses numbers from the rebase instruction sheet. As the rebase code uses `git_futils_readbuffer`, the buffer is always NUL terminated. - revparse: this parses a user provided buffer that is NUL terminated. - signature: this parser the header information of objects. As objects read from the ODB are always NUL terminated, this is a non-issue. The constructor `git_signature_from_buffer` does not accept a length parameter for the buffer, so the buffer needs to be NUL terminated, as well. - smart transport: the buffer that is parsed is NUL terminated - tree cache: this parses the tree cache from the index extension. The index itself is read via `git_futils_readbuffer`, which always NUL terminates it. - winhttp transport: user input is being parsed that is always NUL terminated
fd4e3b21	2018-11-13T15:33:20	Merge pull request #4885 from pks-t/pks/apply-test-fixups apply: small fixups in the test suite
cf83809b	2018-11-13T14:26:26	Merge pull request #4883 from pks-t/pks/signature-tz-oob signature: fix out-of-bounds read when parsing timezone offset
f127ce35	2018-11-13T08:22:25	tests: address two null argument instances Handle two null argument cases that occur in the unit tests. One is in library code, the other is in test code. Detected by running unit tests with undefined behavior sanitizer: ```bash # build mkdir build && cd build cmake -DBUILD_CLAR=ON -DCMAKE_C_FLAGS="-fsanitize=address \ -fsanitize=undefined -fstack-usage -static-libasan" .. cmake --build . # run with asan ASAN_OPTIONS="allocator_may_return_null=1" ./libgit2_clar ... ............../libgit2/src/apply.c:316:3: runtime error: null pointer \ passed as argument 1, which is declared to never be null ...................../libgit2/tests/apply/fromfile.c:46:3: runtime \ error: null pointer passed as argument 1, which is declared to never be null ```
afc64bcd	2018-11-13T14:13:40	tests: apply: fix reference to deprecated `git_buf_free` Since commit 56ffdfc61 (buffer: deprecate `git_buf_free` in favor of `git_buf_dispose`, 2018-02-08), the function `git_buf_free` is deprecated and shall not be used anymore. As part of the new apply framework that has been cooking for quite some time some new references have been introduced to that deprecated function. Replace them with calls to `git_buf_dispose`.
fe215153	2018-11-13T14:08:49	tests: apply: fix missing `cl_git_pass` wrappers Some function calls in the new "apply" test suite were missing the checks whether they succeeded as expected. Fix this by adding the missing `cl_git_pass` wrappers.
20cb30b6	2018-11-13T13:40:17	Merge pull request #4667 from tiennou/feature/remote-create-api Remote creation API
28239be3	2018-11-13T13:27:41	Merge pull request #4818 from pks-t/pks/index-collision Index collision fixes
11fbead8	2018-11-11T16:40:56	Merge pull request #4705 from libgit2/ethomson/apply Patch (diff) application
52f859fd	2018-11-09T19:32:08	signature: fix out-of-bounds read when parsing timezone offset When parsing a signature's timezone offset, we first check whether there is a timezone at all by verifying that there are still bytes left to read following the time itself. The check thus looks like `time_end + 1 < buffer_end`, which is actually correct in this case. After setting the timezone's start pointer to that location, we compute the remaining bytes by using the formula `buffer_end - tz_start + 1`, re-using the previous `time_end + 1`. But this is in fact missing the braces around `(tz_start + 1)`, thus leading to an overestimation of the remaining bytes by a length of two. In case of a non-NUL terminated buffer, this will result in an overflow. The function `git_signature__parse` is only used in two locations. First is `git_signature_from_buffer`, which only accepts a string without a length. The string thus necessarily has to be NUL terminated and cannot trigger the issue. The other function is `git_commit__parse_raw`, which can in fact trigger the error as it may receive non-NUL terminated commit data. But as objects read from the ODB are always NUL-terminated by us as a cautionary measure, it cannot trigger the issue either. In other words, this error does not have any impact on security.
4e746d80	2018-11-05T15:49:11	test: ensure applying a patch can't delete a file twice
f8b9493b	2018-11-05T15:46:08	apply: test re-adding a file after removing it Ensure that we can add a file back after it's been removed. Update the renamed/deleted validation in application to not apply to deltas that are adding files to support this.
78580ad3	2018-11-05T15:34:59	apply: test modifying a file after renaming it Ensure that we cannot modify a file after it's been renamed out of the way. If multiple deltas exist for a single path, ensure that we do not attempt to modify a file after it's been renamed out of the way. To support this, we must track the paths that have been removed or renamed; add to a string map when we remove a path and remove from the string map if we recreate a path. Validate that we are not applying to a path that is in this map, unless the delta is a rename, since git supports renaming one file to two different places in two different deltas. Further, test that we cannot apply a modification delta to a path that will be created in the future by a rename (a path that does not yet exist.)
605066ee	2018-11-05T14:37:35	apply: test renaming a file after modifying it Multiple deltas can exist in a diff, and can be applied in-order. If there exists a delta that modifies a file followed by a delta that renames that file, then both will be captured. The modification delta will be applied and the resulting file will be staged with the original filename. The rename delta will be independently applied - to the original file (not the modified file from the original delta) and staged independently.
bd682f3e	2018-11-04T19:01:57	apply: test that we can't rename a file after modifying it Multiple deltas can exist in a diff, and can be applied in-order. However if there exists a delta that renames a file, it must be first, so that other deltas can reference the resulting target file. git enforces this (`error: already exists in index`), so ensure that we do, too.
a3c1070c	2018-11-04T14:07:22	apply: test modify delta after rename delta Ensure that we can apply a delta after renaming a file.
07e71bfa	2018-11-04T13:14:20	apply: test multiple deltas to new file
df4258ad	2018-11-04T13:01:03	apply: handle multiple deltas to the same file git allows a patch file to contain multiple deltas to the same file: although it does not produce files in this format itself, this could be the result of concatenating two different patch files that affected the same file. git apply behaves by applying this next delta to the existing postimage of the file. We should do the same. If we have previously seen a file, and produced a postimage for it, we will load that postimage and apply the current delta to that. If we have not, get the file from the preimage.
c71e964a	2018-11-04T12:21:57	apply: test rename 1 to 2 Test that a patch can contain two deltas that appear to rename an initial source file to two different destination paths. Git creates both target files with the initial source contents; ensure that we do, too.
56a2ae0c	2018-11-04T12:18:01	apply: test rename 2 to 1 Test that we can apply a patch that renames two different files to the same target filename. Git itself handles this scenario in a last-write wins, such that the rename listed last is the one persisted in the target. Ensure that we do the same.
235dc9b2	2018-11-04T12:05:46	apply: test circular rename Test a rename from A->B simultaneous with a rename from B->A.
89b5a56e	2018-11-04T11:58:20	apply: test rename A -> B -> C scenarios Test that we can rename some file from B->C and then rename some other file from A->B. Do this with both exact rename patches (eg `rename from ...` / `rename to ...`) and patches that remove the files and replace them entirely.
6fecf4d1	2018-11-04T11:47:46	apply: handle exact renames Deltas containing exact renames are special; they simple indicate that a file was renamed without providing additional metadata (like the filemode). Teach the reader to provide the file mode and use the preimage's filemode in the case that the delta does not provide one.)
12f9ac17	2018-11-04T11:26:42	apply: validate unchanged mode when applying both When applying to both the index and the working directory, ensure that the working directory's mode matches the index's mode. It's not sufficient to look only at the hashed object id to determine that the file is unchanged, git also takes the mode into account.
b73a42f6	2018-11-04T10:48:23	apply: test a patch with rename and modification Create a test applying a patch with a rename and a modification of a file.
620ac9c2	2017-04-11T14:41:57	patch: add tests for aborting hunk callback
72630572	2017-03-30T22:40:47	patch: add support for partial patch application Add hunk callback parameter to git_apply__patch to allow hunks to be skipped.
47cc5f85	2018-09-29T19:32:51	apply: introduce a hunk callback Introduce a callback to patch application that allows consumers to cancel hunk application.
398d8bfe	2018-07-16T17:19:08	apply tests: tests a diff w/ many small changes
b8840db7	2018-07-10T16:18:45	apply tests: test delta callback skip Test that we can return a non-zero value from the apply delta callback and it will skip the application of a given delta.
db6b1164	2018-07-10T16:13:17	apply tests: test delta callback errors Test that we can return an error from the apply delta callback and the error code is propagated back to the caller.
37b25ac5	2018-07-08T16:12:58	apply: move location to an argument, not the opts Move the location option to an argument, out of the options structure. This allows the options structure to be re-used for functions that don't need to know the location, since it's implicit in their functionality. For example, `git_apply_tree` should not take a location, but is expected to take all the other options.
eb76e985	2018-07-01T21:21:25	apply tests: ensure mode changes occur Test that a mode change is reflected in the working directory or index.
5c63ce79	2018-07-01T11:10:03	apply tests: test with CR/LF filtering Ensure that we accurately CR/LF filter when reading from the working directory. If we did not, we would erroneously fail to apply the patch because the index contents did not match the working directory contents.
813f0802	2018-07-01T15:14:36	apply: validate workdir contents match index for BOTH When applying to both the index and the working directory, ensure that the index contents match the working directory. This mirrors the requirement in `git apply --index`. This also means that - along with the prior commit that uses the working directory contents as the checkout baseline - we no longer expect conflicts during checkout. So remove the special-case error handling for checkout conflicts. (Any checkout conflict now would be because the file was actually modified between the start of patch application and the checkout.)
3b674660	2018-07-01T13:46:59	apply tests: ensure we can patch a modified file Patch application need not be on an unmodified file; applying to an already changed file is supported provided the patch still applies cleanly. Add tests that modifies the contents of a file then applies the patch and ensures that the patch applies cleanly, and the original changes are also kept.
4ff829e9	2018-06-30T17:20:03	apply tests: test index+workdir application Test application with `GIT_APPLY_LOCATION_BOTH`, which emulates `git apply --index`, updating both the index and the working directory with the postimage.
9db66c79	2018-06-29T12:50:38	apply test: apply with non-conflicting changes Ensure that we can apply to the working directory or the index when the application target is modified, so long as there are not conflicting changes to the items.
771bd81e	2018-06-29T12:40:16	apply tests: ensure apply failures leave index unmodified
2bd3cfea	2018-06-29T11:43:55	apply tests: modified wd items are ok when applying to index When applying to the index (using `GIT_APPLY_LOCATION_INDEX`), ensure that items modified in the working directory do not conflict with the application.
d7090ee4	2018-06-28T17:26:24	apply tests: ensure we can add and remove files from the index Add a test that adds a new file, and another that removes a file when applying using `GIT_APPLY_LOCATION_INDEX` to ensure that they work.
9d81defa	2018-06-28T16:26:08	apply tests: GIT_APPLY_LOCATION_INDEX with parsed patches
eef34e4e	2018-06-28T16:24:21	apply tests: GIT_APPLY_LOCATION_INDEX with generated patches Test a simple patch application with `GIT_APPLY_LOCATION_INDEX`, which emulates `git apply --cached`.
c010c93b	2018-06-27T16:50:07	apply tests: move helpers into common area
35d525b0	2018-06-26T09:19:12	apply: test that failures don't dirty workdir Ensure that when a patch application fails (due to a conflict in the working directory, for example) that we do not half-apply the patch or otherwise leave the working directory dirty. This is rather obvious in our current apply implementation (we do a two step process: one to create the post-image and one to check it out) but this test is a safety net for future refactoring or improvements.
973bf0c8	2018-06-25T20:49:22	apply: test a patch can be applied even with a modified index Ensure that we can apply a patch to the working directory, even to files that are modified in the index (as long as the working directory contents match the preimage - such that the working directory is unmodified from HEAD).
553395dc	2018-06-25T20:21:01	apply: test that the index is not modified Ensure that by default, when using GIT_APPLY_LOCATION_WORKDIR, that patch application does not update the index, only the working directory.
0eb63b9f	2018-06-25T19:50:35	apply tests: separate common patch hunks Move the commonly-used patch hunks into a single constant location. This allows us to avoid re-declaring them in each test, and allows us to compose them to build a larger patch file that includes all the hunks.
702d4bec	2018-06-26T15:26:37	apply tests: use `git_iterator_foreach` for tests Use the new `git_iterator_foreach` API to validate the workdir against the expected workdir values instead of using the paired/multi iterator comparison callback. This allows us to use the `git_iterator_foreach` to validate the index as well, instead of assuming that the index and HEAD must always match.
9c34c996	2018-06-25T17:03:14	apply: handle file additions Don't attempt to read the postimage file during a file addition, simply use an empty buffer as the postimage. Also, test that we can handle file additions.
3b5378c5	2018-06-25T16:27:06	apply: handle file deletions If the file was deleted in the postimage, do not attempt to update the target. Instead, ignore it and simply allow it to stay removed in our computed postimage. Also, test that we can handle file deletions.
af3287f8	2018-06-22T19:27:19	apply: test `git_apply` with a parsed patch Ensure that we can apply a simple patch to the working directory when we have parsed it from a patch file.
ff296b71	2018-03-19T19:50:52	apply: test `git_apply` application to a workdir Introduce a standard test applying a diff to a working directory with no complications.
02b1083a	2018-01-28T23:25:07	apply: introduce `git_apply_tree` Introduce `git_apply_tree`, which will apply a `git_diff` to a given `git_tree`, allowing an in-memory patch application for a repository.
2b12dcf6	2018-03-19T19:45:11	iterator: optionally hash filesystem iterators Optionally hash the contents of files encountered in the filesystem or working directory iterators. This is not expected to be used in production code paths, but may allow us to simplify some test contexts. For working directory iterators, apply filters as appropriate, since we have the context able to do it.
666c7bd8	2018-10-08T20:51:45	tests: unwarranted NULL-ification
3652b83a	2018-06-22T21:36:01	tests: remote/create: remove macro and unroll tests
d3650294	2018-06-20T02:27:14	remote: add a flag to prevent generation of the default fetchspec
fdb116b3	2018-06-20T02:27:12	remote: add a creation flag for ignoring url.insteadOf
3cbaebdf	2018-06-20T02:27:11	remote: provide a generic API for creating remotes This supersedes the functionality of remote_create_with_fetchspec, remote_create_anonymous and remote_create_detached.
0e5a27cd	2018-06-20T02:26:58	tests: count config section helper already exists
f8fc987c	2018-06-20T02:26:56	tests: git_remote_create_detached
4e0da450	2018-06-20T02:26:55	tests: check what happens with the remote. section counts
f778af68	2018-06-20T02:26:53	tests: git_remote_create_anonymous
fa69195e	2018-06-20T02:26:52	tests: git_remote_create_with_fetchspec
10fa2dd6	2018-06-20T02:26:50	tests: consolidate all remote creation tests in one test suite
798be87e	2018-06-20T02:26:49	tests: rename remote creation test suite
7fafec0e	2018-10-29T18:32:39	tree: fix integer overflow when reading unreasonably large filemodes The `parse_mode` option uses an open-coded octal number parser. The parser is quite naive in that it simply parses until hitting a character that is not in the accepted range of '0' - '7', completely ignoring the fact that we can at most accept a 16 bit unsigned integer as filemode. If the filemode is bigger than UINT16_MAX, it will thus overflow and provide an invalid filemode for the object entry. Fix the issue by using `git__strntol32` instead and doing a bounds check. As this function already handles overflows, it neatly solves the problem. Note that previously, `parse_mode` was also skipping the character immediately after the filemode. In proper trees, this should be a simple space, but in fact the parser accepted any character and simply skipped over it. As a consequence of using `git__strntol32`, we now need to an explicit check for a trailing whitespace after having parsed the filemode. Because of the newly introduced error message, the test object::tree::parse::mode_doesnt_cause_oob_read needs adjustment to its error message check, which in fact is a good thing as it demonstrates that we now fail looking for the whitespace immediately following the filemode. Add a test that shows that we will fail to parse such invalid filemodes now.
f647bbc8	2018-10-29T17:25:09	tree: fix mode parsing reading out-of-bounds When parsing a tree entry's mode, we will eagerly parse until we hit a character that is not in the accepted set of octal digits '0' - '7'. If the provided buffer is not a NUL terminated one, we may thus read out-of-bounds. Fix the issue by passing the buffer length to `parse_mode` and paying attention to it. Note that this is not a vulnerability in our usual code paths, as all object data read from the ODB is NUL terminated.
d4ad658a	2018-10-29T17:24:47	tree: add various tests exercising the tree parser We currently don't have any tests that directly exercise the tree parser. This is due to the fact that the parsers for raw object data has only been recently introduce with commit ca4db5f4a (object: implement function to parse raw data, 2017-10-13), and previous to that the setup simply was too cumbersome as it always required going through the ODB. Now that we have the infrastructure, add a suite of tests that directly exercise the tree parser and various edge cases.
50d09407	2018-10-29T18:05:27	strntol: fix detection and skipping of base prefixes The `git__strntol` family of functions has the ability to auto-detect a number's base if the string has either the common '0x' prefix for hexadecimal numbers or '0' prefix for octal numbers. The detection of such prefixes and following handling has two major issues though that are being fixed in one go now. - We do not do any bounds checking previous to verifying the '0x' base. While we do verify that there is at least one digit available previously, we fail to verify that there are two digits available and thus may do an out-of-bounds read when parsing this two-character-prefix. - When skipping the prefix of such numbers, we only update the pointer length without also updating the number of remaining bytes. Thus if we try to parse a number '0x1' of total length 3, we will first skip the first two bytes and then try to read 3 bytes starting at '1'. Fix both issues by disentangling the logic. Instead of doing the detection and skipping of such prefixes in one go, we will now first try to detect the base while also honoring how many bytes are left. Only if we have a valid base that is either 8 or 16 and have one of the known prefixes, we will now advance the pointer and update the remaining bytes in one step. Add some tests that verify that no out-of-bounds parsing happens and that autodetection works as advertised.
41863a00	2018-10-29T17:19:58	strntol: fix out-of-bounds read when skipping leading spaces The `git__strntol` family of functions accepts leading spaces and will simply skip them. The skipping will not honor the provided buffer's length, though, which may lead it to read outside of the provided buffer's bounds if it is not a simple NUL-terminated string. Furthermore, if leading space is trimmed, the function will further advance the pointer but not update the number of remaining bytes, which may also lead to out-of-bounds reads. Fix the issue by properly paying attention to the buffer length and updating it when stripping leading whitespace characters. Add a test that verifies that we won't read past the provided buffer length.
b5ae83bf	2018-10-31T08:47:10	Merge pull request #4860 from tiennou/ci/macos-leaks CI: Fix macOS leak detection
0e69485e	2018-10-23T20:34:47	clar: provide a way to run some shell before exiting
623647af	2018-10-26T12:33:59	Merge pull request #4864 from pks-t/pks/object-parse-fixes Object parse fixes
7655b2d8	2018-10-19T10:29:19	commit: fix reading out of bounds when parsing encoding The commit message encoding is currently being parsed by the `git__prefixcmp` function. As this function does not accept a buffer length, it will happily skip over a buffer's end if it is not `NUL` terminated. Fix the issue by using `git__prefixncmp` instead. Add a test that verifies that we are unable to parse the encoding field if it's cut off by the supplied buffer length.
c2e3d8ef	2018-10-25T12:01:18	tests: add tests that exercise commit parsing We currently do not have any test suites dedicated to parsing commits from their raw representations. Add one based on `git_object__from_raw` to be able to test special cases more easily.
ee11d47e	2018-10-19T09:47:50	tag: fix out of bounds read when searching for tag message When parsing tags, we skip all unknown fields that appear before the tag message. This skipping is done by using a plain `strstr(buffer, "\n\n")` to search for the two newlines that separate tag fields from tag message. As it is not possible to supply a buffer length to `strstr`, this call may skip over the buffer's end and thus result in an out of bounds read. As `strstr` may return a pointer that is out of bounds, the following computation of `buffer_end - buffer` will overflow and result in an allocation of an invalid length. Fix the issue by using `git__memmem` instead. Add a test that verifies parsing the tag fails not due to the allocation failure but due to the tag having no message.
4c738e56	2018-10-19T09:44:14	tests: add tests that exercise tag parsing While the tests in object::tag::read exercises reading and parsing valid tags from the ODB, they barely try to verify that the parser fails in a sane way when parsing invalid tags. Create a new test suite object::tag::parse that directly exercise the parser by using `git_object__from_raw` and add various tests for valid and invalid tags.
83e8a6b3	2018-10-18T16:08:46	util: provide `git__memmem` function Unfortunately, neither the `memmem` nor the `strnstr` functions are part of any C standard but are merely extensions of C that are implemented by e.g. glibc. Thus, there is no standardized way to search for a string in a block of memory with a limited size, and using `strstr` is to be considered unsafe in case where the buffer has not been sanitized. In fact, there are some uses of `strstr` in exactly that unsafe way in our codebase. Provide a new function `git__memmem` that implements the `memmem` semantics. That is in a given haystack of `n` bytes, search for the occurrence of a byte sequence of `m` bytes and return a pointer to the first occurrence. The implementation chosen is the "Not So Naive" algorithm from [1]. It was chosen as the implementation is comparably simple while still being reasonably efficient in most cases. Preprocessing happens in constant time and space, searching has a time complexity of O(n*m) with a slightly sub-linear average case. [1]: http://www-igm.univ-mlv.fr/~lecroq/string/
bea65980	2018-10-25T11:21:14	Merge pull request #4851 from pks-t/pks/strtol-removal strtol removal
2e34efaa	2018-10-21T13:10:06	buf::oom tests: use custom allocator for oom failures Create a custom allocator for the `buf::oom` tests that will fail with out-of-memory errors in predictable ways. We were previously trying to guess the way that various allocators on various platforms would fail in a way such that `malloc`/`realloc` would return `NULL` (instead of aborting the application, or appearing suspicious to various instrumentation or static code analysis tools like valgrind.) Introduce a fake `malloc` and `realloc` that will return `NULL` on allocations requesting more than 100 bytes. Otherwise, we proxy to the default allocator. (It's important to use the _default_ allocator, not just call `malloc`, since the default allocator on Windows CI builds may be the debugging C runtime allocators which would not be compatible with a standard `malloc`.)
415a8ae9	2018-09-13T13:27:07	tests: don't run buf::oom on 32-bit systems On a 32-bit Linux systems, the value large enough to make malloc guarantee a failure is also large enough that valgrind considers it "fishy". Skip this test on those systems entirely.
7c791f3d	2018-10-20T20:25:51	Merge pull request #4852 from libgit2/ethomson/unc_paths Win32 path canonicalization refactoring
6cc14ae3	2018-10-20T20:22:04	Merge pull request #4840 from libgit2/cmn/validity-tree-from-unowned-index Check object existence when creating a tree from an index
a2f9f94b	2018-10-20T20:18:04	Merge branch 'issue-4203'
c79e6081	2018-10-20T19:08:16	checkout: fix test fixture missing objects The testrepo test fixture has an index file that's damaged, missing an object. The index previously had an entry of `src/index.c` with id 3161df8cbf3a006b4ef85be6497a0ea6bde98541, but that object was missing in the repository. This commit adds an object to the repository and updates the index to use that existing blob. Similarly, the index has an entry for `readme` with an id of 97328ac7e3bd0bcd3900cb3e7a624d71dd0df888. This can be restored from other test repositories. With these fixed, now the write tree from index tests can pass since they validate object existence.
da500cc6	2018-10-20T05:43:40	symlink tests: test symbolic links on windows Test updated symbolic link creation on Windows. Ensure that we emulate Git for Windows behavior. Ensure that when `core.symlinks=true` is set in a global configuration that new repositories are created without a `core.symlinks` setting, and that when `core.symlinks` is unset that `core.symlinks=false` in set in the repository. Further ensure that checkout honors the expected `core.symlinks` defaults on Windows.
3f0caa15	2018-10-20T02:49:49	repo::init tests: refactor global config path override Provide a function that allows tests to set up a bespoke global configuration path.
628dae8b	2018-10-19T03:14:35	tests: provide symlink support helper function
df1733de	2018-07-16T05:16:41	checkout tests: ensure readlink succeeds Don't try to use `link_size` as an index into a string if `p_readlink` returned <0. That will - obviously - fail and we'll write out of bounds.
8533c80d	2018-07-03T02:51:40	repo tests: ensure core.symlinks is set correctly Ensure that `core.symlinks` is set correctly. By default, it is unset, but it is explicitly set to `false` if the platform was detected to not support symlinks during repository initialization.
e4ac4000	2018-07-02T12:57:56	checkout tests: test symlinks based on support, not platform When testing whether symlinks are correctly checked out, examine the `core.symlinks` configuration option to determine if symlinks are supported in a repository, don't simply assume that Windows means that symbolic links are not supported. Further, when testing the expected default behavior of `core.symlinks`, test the filesystem's support to determine if symlinks are supported. Finally, ensure that `core.symlinks=true` fails on a system where symlinks are actually not supported. This aligns with the behavior of Git for Windows.

14a9a4f3

2018-11-21T11:18:46

tests: move apply_helpers functions into own compilation unit Currently, the "apply_helper" functions used for testing the apply logic are all statically defined in the "apply_helpers.h" header file. This may lead to warnings from the compiler in case where this header file is included, but not all functions it brings along are used in the compilation unit where it has been included into. Fix these potential warnings by moving the implementation into its own compilation unit "apply_helpers.c".

0e3e832d

2018-11-21T13:30:01

Merge pull request #4884 from libgit2/ethomson/index_iterator index: introduce git_index_iterator

11d33df8

2018-11-18T23:39:43

Merge branch 'tiennou/fix/logallrefupdates-always'

e226ad8f

2018-11-17T17:55:10

refs: add support for core.logAllRefUpdates=always Since we were not expecting this config entry to contain a string, we would fail as soon as its (cached) value would be accessed. Hence, provide some constants for the 4 states we use, and account for "always" when we decide to reflog changes.

646a94be

2018-11-18T23:15:56

Merge pull request #4847 from noahp/noahp/null-arg-fixes tests: 🌀 address two null argument instances

7321cff0

2018-11-15T09:17:51

Merge pull request #4713 from libgit2/ethomson/win_symlinks Support symlinks on Windows when core.symlinks=true

c358bbc5

2018-11-12T17:22:47

index: introduce git_index_iterator Provide a public git_index_iterator API that is backed by an index snapshot. This allows consumers to provide a stable iteration even while manipulating the index during iteration.

4209a512

2018-11-14T12:04:42

strntol: fix out-of-bounds reads when parsing numbers with leading sign When parsing a number, we accept a leading plus or minus sign to return a positive or negative number. When the parsed string has such a leading sign, we set up a flag indicating that the number is negative and advance the pointer to the next character in that string. This misses updating the number of bytes in the string, though, which is why the parser may later on do an out-of-bounds read. Fix the issue by correctly updating both the pointer and the number of remaining bytes. Furthermore, we need to check whether we actually have any bytes left after having advanced the pointer, as otherwise the auto-detection of the base may do an out-of-bonuds access. Add a test that detects the out-of-bound read. Note that this is not actually security critical. While there are a lot of places where the function is called, all of these places are guarded or irrelevant: - commit list: this operates on objects from the ODB, which are always NUL terminated any may thus not trigger the off-by-one OOB read. - config: the configuration is NUL terminated. - curl stream: user input is being parsed that is always NUL terminated - index: the index is read via `git_futils_readbuffer`, which always NUL terminates it. - loose objects: used to parse the length from the object's header. As we check previously that the buffer contains a NUL byte, this is safe. - rebase: this parses numbers from the rebase instruction sheet. As the rebase code uses `git_futils_readbuffer`, the buffer is always NUL terminated. - revparse: this parses a user provided buffer that is NUL terminated. - signature: this parser the header information of objects. As objects read from the ODB are always NUL terminated, this is a non-issue. The constructor `git_signature_from_buffer` does not accept a length parameter for the buffer, so the buffer needs to be NUL terminated, as well. - smart transport: the buffer that is parsed is NUL terminated - tree cache: this parses the tree cache from the index extension. The index itself is read via `git_futils_readbuffer`, which always NUL terminates it. - winhttp transport: user input is being parsed that is always NUL terminated

fd4e3b21

2018-11-13T15:33:20

Merge pull request #4885 from pks-t/pks/apply-test-fixups apply: small fixups in the test suite

cf83809b

2018-11-13T14:26:26

Merge pull request #4883 from pks-t/pks/signature-tz-oob signature: fix out-of-bounds read when parsing timezone offset

f127ce35

2018-11-13T08:22:25

tests: address two null argument instances Handle two null argument cases that occur in the unit tests. One is in library code, the other is in test code. Detected by running unit tests with undefined behavior sanitizer: ```bash # build mkdir build && cd build cmake -DBUILD_CLAR=ON -DCMAKE_C_FLAGS="-fsanitize=address \ -fsanitize=undefined -fstack-usage -static-libasan" .. cmake --build . # run with asan ASAN_OPTIONS="allocator_may_return_null=1" ./libgit2_clar ... ............../libgit2/src/apply.c:316:3: runtime error: null pointer \ passed as argument 1, which is declared to never be null ...................../libgit2/tests/apply/fromfile.c:46:3: runtime \ error: null pointer passed as argument 1, which is declared to never be null ```

afc64bcd

2018-11-13T14:13:40

tests: apply: fix reference to deprecated `git_buf_free` Since commit 56ffdfc61 (buffer: deprecate `git_buf_free` in favor of `git_buf_dispose`, 2018-02-08), the function `git_buf_free` is deprecated and shall not be used anymore. As part of the new apply framework that has been cooking for quite some time some new references have been introduced to that deprecated function. Replace them with calls to `git_buf_dispose`.

fe215153

2018-11-13T14:08:49

tests: apply: fix missing `cl_git_pass` wrappers Some function calls in the new "apply" test suite were missing the checks whether they succeeded as expected. Fix this by adding the missing `cl_git_pass` wrappers.

20cb30b6

2018-11-13T13:40:17

Merge pull request #4667 from tiennou/feature/remote-create-api Remote creation API

28239be3

2018-11-13T13:27:41

Merge pull request #4818 from pks-t/pks/index-collision Index collision fixes

11fbead8

2018-11-11T16:40:56

Merge pull request #4705 from libgit2/ethomson/apply Patch (diff) application

52f859fd

2018-11-09T19:32:08

signature: fix out-of-bounds read when parsing timezone offset When parsing a signature's timezone offset, we first check whether there is a timezone at all by verifying that there are still bytes left to read following the time itself. The check thus looks like `time_end + 1 < buffer_end`, which is actually correct in this case. After setting the timezone's start pointer to that location, we compute the remaining bytes by using the formula `buffer_end - tz_start + 1`, re-using the previous `time_end + 1`. But this is in fact missing the braces around `(tz_start + 1)`, thus leading to an overestimation of the remaining bytes by a length of two. In case of a non-NUL terminated buffer, this will result in an overflow. The function `git_signature__parse` is only used in two locations. First is `git_signature_from_buffer`, which only accepts a string without a length. The string thus necessarily has to be NUL terminated and cannot trigger the issue. The other function is `git_commit__parse_raw`, which can in fact trigger the error as it may receive non-NUL terminated commit data. But as objects read from the ODB are always NUL-terminated by us as a cautionary measure, it cannot trigger the issue either. In other words, this error does not have any impact on security.

4e746d80

2018-11-05T15:49:11

test: ensure applying a patch can't delete a file twice

f8b9493b

2018-11-05T15:46:08

apply: test re-adding a file after removing it Ensure that we can add a file back after it's been removed. Update the renamed/deleted validation in application to not apply to deltas that are adding files to support this.

78580ad3

2018-11-05T15:34:59

apply: test modifying a file after renaming it Ensure that we cannot modify a file after it's been renamed out of the way. If multiple deltas exist for a single path, ensure that we do not attempt to modify a file after it's been renamed out of the way. To support this, we must track the paths that have been removed or renamed; add to a string map when we remove a path and remove from the string map if we recreate a path. Validate that we are not applying to a path that is in this map, unless the delta is a rename, since git supports renaming one file to two different places in two different deltas. Further, test that we cannot apply a modification delta to a path that will be created in the future by a rename (a path that does not yet exist.)

605066ee

2018-11-05T14:37:35

apply: test renaming a file after modifying it Multiple deltas can exist in a diff, and can be applied in-order. If there exists a delta that modifies a file followed by a delta that renames that file, then both will be captured. The modification delta will be applied and the resulting file will be staged with the original filename. The rename delta will be independently applied - to the original file (not the modified file from the original delta) and staged independently.

bd682f3e

2018-11-04T19:01:57

apply: test that we can't rename a file after modifying it Multiple deltas can exist in a diff, and can be applied in-order. However if there exists a delta that renames a file, it must be first, so that other deltas can reference the resulting target file. git enforces this (`error: already exists in index`), so ensure that we do, too.

a3c1070c

2018-11-04T14:07:22

apply: test modify delta after rename delta Ensure that we can apply a delta after renaming a file.

07e71bfa

2018-11-04T13:14:20

apply: test multiple deltas to new file

df4258ad

2018-11-04T13:01:03

apply: handle multiple deltas to the same file git allows a patch file to contain multiple deltas to the same file: although it does not produce files in this format itself, this could be the result of concatenating two different patch files that affected the same file. git apply behaves by applying this next delta to the existing postimage of the file. We should do the same. If we have previously seen a file, and produced a postimage for it, we will load that postimage and apply the current delta to that. If we have not, get the file from the preimage.

c71e964a

2018-11-04T12:21:57

apply: test rename 1 to 2 Test that a patch can contain two deltas that appear to rename an initial source file to two different destination paths. Git creates both target files with the initial source contents; ensure that we do, too.

56a2ae0c

2018-11-04T12:18:01

apply: test rename 2 to 1 Test that we can apply a patch that renames two different files to the same target filename. Git itself handles this scenario in a last-write wins, such that the rename listed last is the one persisted in the target. Ensure that we do the same.

235dc9b2

2018-11-04T12:05:46

apply: test circular rename Test a rename from A->B simultaneous with a rename from B->A.

89b5a56e

2018-11-04T11:58:20

apply: test rename A -> B -> C scenarios Test that we can rename some file from B->C and then rename some other file from A->B. Do this with both exact rename patches (eg `rename from ...` / `rename to ...`) and patches that remove the files and replace them entirely.

6fecf4d1

2018-11-04T11:47:46

apply: handle exact renames Deltas containing exact renames are special; they simple indicate that a file was renamed without providing additional metadata (like the filemode). Teach the reader to provide the file mode and use the preimage's filemode in the case that the delta does not provide one.)

12f9ac17

2018-11-04T11:26:42

apply: validate unchanged mode when applying both When applying to both the index and the working directory, ensure that the working directory's mode matches the index's mode. It's not sufficient to look only at the hashed object id to determine that the file is unchanged, git also takes the mode into account.

b73a42f6

2018-11-04T10:48:23

apply: test a patch with rename and modification Create a test applying a patch with a rename and a modification of a file.

620ac9c2

2017-04-11T14:41:57

patch: add tests for aborting hunk callback

72630572

2017-03-30T22:40:47

patch: add support for partial patch application Add hunk callback parameter to git_apply__patch to allow hunks to be skipped.

47cc5f85

2018-09-29T19:32:51

apply: introduce a hunk callback Introduce a callback to patch application that allows consumers to cancel hunk application.

398d8bfe

2018-07-16T17:19:08

apply tests: tests a diff w/ many small changes

b8840db7

2018-07-10T16:18:45

apply tests: test delta callback skip Test that we can return a non-zero value from the apply delta callback and it will skip the application of a given delta.

db6b1164

2018-07-10T16:13:17

apply tests: test delta callback errors Test that we can return an error from the apply delta callback and the error code is propagated back to the caller.

37b25ac5

2018-07-08T16:12:58

apply: move location to an argument, not the opts Move the location option to an argument, out of the options structure. This allows the options structure to be re-used for functions that don't need to know the location, since it's implicit in their functionality. For example, `git_apply_tree` should not take a location, but is expected to take all the other options.

eb76e985

2018-07-01T21:21:25

apply tests: ensure mode changes occur Test that a mode change is reflected in the working directory or index.

5c63ce79

2018-07-01T11:10:03

apply tests: test with CR/LF filtering Ensure that we accurately CR/LF filter when reading from the working directory. If we did not, we would erroneously fail to apply the patch because the index contents did not match the working directory contents.

813f0802

2018-07-01T15:14:36

apply: validate workdir contents match index for BOTH When applying to both the index and the working directory, ensure that the index contents match the working directory. This mirrors the requirement in `git apply --index`. This also means that - along with the prior commit that uses the working directory contents as the checkout baseline - we no longer expect conflicts during checkout. So remove the special-case error handling for checkout conflicts. (Any checkout conflict now would be because the file was actually modified between the start of patch application and the checkout.)

3b674660

2018-07-01T13:46:59

apply tests: ensure we can patch a modified file Patch application need not be on an unmodified file; applying to an already changed file is supported provided the patch still applies cleanly. Add tests that modifies the contents of a file then applies the patch and ensures that the patch applies cleanly, and the original changes are also kept.

4ff829e9

2018-06-30T17:20:03

apply tests: test index+workdir application Test application with `GIT_APPLY_LOCATION_BOTH`, which emulates `git apply --index`, updating both the index and the working directory with the postimage.

9db66c79

2018-06-29T12:50:38

apply test: apply with non-conflicting changes Ensure that we can apply to the working directory or the index when the application target is modified, so long as there are not conflicting changes to the items.

771bd81e

2018-06-29T12:40:16

apply tests: ensure apply failures leave index unmodified

2bd3cfea

2018-06-29T11:43:55

apply tests: modified wd items are ok when applying to index When applying to the index (using `GIT_APPLY_LOCATION_INDEX`), ensure that items modified in the working directory do not conflict with the application.

d7090ee4

2018-06-28T17:26:24

apply tests: ensure we can add and remove files from the index Add a test that adds a new file, and another that removes a file when applying using `GIT_APPLY_LOCATION_INDEX` to ensure that they work.

9d81defa

2018-06-28T16:26:08

apply tests: GIT_APPLY_LOCATION_INDEX with parsed patches

eef34e4e

2018-06-28T16:24:21

apply tests: GIT_APPLY_LOCATION_INDEX with generated patches Test a simple patch application with `GIT_APPLY_LOCATION_INDEX`, which emulates `git apply --cached`.

c010c93b

2018-06-27T16:50:07

apply tests: move helpers into common area

35d525b0

2018-06-26T09:19:12

apply: test that failures don't dirty workdir Ensure that when a patch application fails (due to a conflict in the working directory, for example) that we do not half-apply the patch or otherwise leave the working directory dirty. This is rather obvious in our current apply implementation (we do a two step process: one to create the post-image and one to check it out) but this test is a safety net for future refactoring or improvements.

973bf0c8

2018-06-25T20:49:22

apply: test a patch can be applied even with a modified index Ensure that we can apply a patch to the working directory, even to files that are modified in the index (as long as the working directory contents match the preimage - such that the working directory is unmodified from HEAD).

553395dc

2018-06-25T20:21:01

apply: test that the index is not modified Ensure that by default, when using GIT_APPLY_LOCATION_WORKDIR, that patch application does not update the index, only the working directory.

0eb63b9f

2018-06-25T19:50:35

apply tests: separate common patch hunks Move the commonly-used patch hunks into a single constant location. This allows us to avoid re-declaring them in each test, and allows us to compose them to build a larger patch file that includes all the hunks.

702d4bec

2018-06-26T15:26:37

apply tests: use `git_iterator_foreach` for tests Use the new `git_iterator_foreach` API to validate the workdir against the expected workdir values instead of using the paired/multi iterator comparison callback. This allows us to use the `git_iterator_foreach` to validate the index as well, instead of assuming that the index and HEAD must always match.

9c34c996

2018-06-25T17:03:14

apply: handle file additions Don't attempt to read the postimage file during a file addition, simply use an empty buffer as the postimage. Also, test that we can handle file additions.

3b5378c5

2018-06-25T16:27:06

apply: handle file deletions If the file was deleted in the postimage, do not attempt to update the target. Instead, ignore it and simply allow it to stay removed in our computed postimage. Also, test that we can handle file deletions.

af3287f8

2018-06-22T19:27:19

apply: test `git_apply` with a parsed patch Ensure that we can apply a simple patch to the working directory when we have parsed it from a patch file.

ff296b71

2018-03-19T19:50:52

apply: test `git_apply` application to a workdir Introduce a standard test applying a diff to a working directory with no complications.

02b1083a

2018-01-28T23:25:07

apply: introduce `git_apply_tree` Introduce `git_apply_tree`, which will apply a `git_diff` to a given `git_tree`, allowing an in-memory patch application for a repository.

2b12dcf6

2018-03-19T19:45:11

iterator: optionally hash filesystem iterators Optionally hash the contents of files encountered in the filesystem or working directory iterators. This is not expected to be used in production code paths, but may allow us to simplify some test contexts. For working directory iterators, apply filters as appropriate, since we have the context able to do it.

666c7bd8

2018-10-08T20:51:45

tests: unwarranted NULL-ification

3652b83a

2018-06-22T21:36:01

tests: remote/create: remove macro and unroll tests

d3650294

2018-06-20T02:27:14

remote: add a flag to prevent generation of the default fetchspec

fdb116b3

2018-06-20T02:27:12

remote: add a creation flag for ignoring url.insteadOf

3cbaebdf

2018-06-20T02:27:11

remote: provide a generic API for creating remotes This supersedes the functionality of remote_create_with_fetchspec, remote_create_anonymous and remote_create_detached.

0e5a27cd

2018-06-20T02:26:58

tests: count config section helper already exists

f8fc987c

2018-06-20T02:26:56

tests: git_remote_create_detached

4e0da450

2018-06-20T02:26:55

tests: check what happens with the remote. section counts

f778af68

2018-06-20T02:26:53

tests: git_remote_create_anonymous

fa69195e

2018-06-20T02:26:52

tests: git_remote_create_with_fetchspec

10fa2dd6

2018-06-20T02:26:50

tests: consolidate all remote creation tests in one test suite

798be87e

2018-06-20T02:26:49

tests: rename remote creation test suite

7fafec0e

2018-10-29T18:32:39

tree: fix integer overflow when reading unreasonably large filemodes The `parse_mode` option uses an open-coded octal number parser. The parser is quite naive in that it simply parses until hitting a character that is not in the accepted range of '0' - '7', completely ignoring the fact that we can at most accept a 16 bit unsigned integer as filemode. If the filemode is bigger than UINT16_MAX, it will thus overflow and provide an invalid filemode for the object entry. Fix the issue by using `git__strntol32` instead and doing a bounds check. As this function already handles overflows, it neatly solves the problem. Note that previously, `parse_mode` was also skipping the character immediately after the filemode. In proper trees, this should be a simple space, but in fact the parser accepted any character and simply skipped over it. As a consequence of using `git__strntol32`, we now need to an explicit check for a trailing whitespace after having parsed the filemode. Because of the newly introduced error message, the test object::tree::parse::mode_doesnt_cause_oob_read needs adjustment to its error message check, which in fact is a good thing as it demonstrates that we now fail looking for the whitespace immediately following the filemode. Add a test that shows that we will fail to parse such invalid filemodes now.

f647bbc8

2018-10-29T17:25:09

tree: fix mode parsing reading out-of-bounds When parsing a tree entry's mode, we will eagerly parse until we hit a character that is not in the accepted set of octal digits '0' - '7'. If the provided buffer is not a NUL terminated one, we may thus read out-of-bounds. Fix the issue by passing the buffer length to `parse_mode` and paying attention to it. Note that this is not a vulnerability in our usual code paths, as all object data read from the ODB is NUL terminated.

d4ad658a

2018-10-29T17:24:47

tree: add various tests exercising the tree parser We currently don't have any tests that directly exercise the tree parser. This is due to the fact that the parsers for raw object data has only been recently introduce with commit ca4db5f4a (object: implement function to parse raw data, 2017-10-13), and previous to that the setup simply was too cumbersome as it always required going through the ODB. Now that we have the infrastructure, add a suite of tests that directly exercise the tree parser and various edge cases.

50d09407

2018-10-29T18:05:27

strntol: fix detection and skipping of base prefixes The `git__strntol` family of functions has the ability to auto-detect a number's base if the string has either the common '0x' prefix for hexadecimal numbers or '0' prefix for octal numbers. The detection of such prefixes and following handling has two major issues though that are being fixed in one go now. - We do not do any bounds checking previous to verifying the '0x' base. While we do verify that there is at least one digit available previously, we fail to verify that there are two digits available and thus may do an out-of-bounds read when parsing this two-character-prefix. - When skipping the prefix of such numbers, we only update the pointer length without also updating the number of remaining bytes. Thus if we try to parse a number '0x1' of total length 3, we will first skip the first two bytes and then try to read 3 bytes starting at '1'. Fix both issues by disentangling the logic. Instead of doing the detection and skipping of such prefixes in one go, we will now first try to detect the base while also honoring how many bytes are left. Only if we have a valid base that is either 8 or 16 and have one of the known prefixes, we will now advance the pointer and update the remaining bytes in one step. Add some tests that verify that no out-of-bounds parsing happens and that autodetection works as advertised.

41863a00

2018-10-29T17:19:58

strntol: fix out-of-bounds read when skipping leading spaces The `git__strntol` family of functions accepts leading spaces and will simply skip them. The skipping will not honor the provided buffer's length, though, which may lead it to read outside of the provided buffer's bounds if it is not a simple NUL-terminated string. Furthermore, if leading space is trimmed, the function will further advance the pointer but not update the number of remaining bytes, which may also lead to out-of-bounds reads. Fix the issue by properly paying attention to the buffer length and updating it when stripping leading whitespace characters. Add a test that verifies that we won't read past the provided buffer length.

b5ae83bf

2018-10-31T08:47:10

Merge pull request #4860 from tiennou/ci/macos-leaks CI: Fix macOS leak detection

0e69485e

2018-10-23T20:34:47

clar: provide a way to run some shell before exiting

623647af

2018-10-26T12:33:59

Merge pull request #4864 from pks-t/pks/object-parse-fixes Object parse fixes

7655b2d8

2018-10-19T10:29:19

commit: fix reading out of bounds when parsing encoding The commit message encoding is currently being parsed by the `git__prefixcmp` function. As this function does not accept a buffer length, it will happily skip over a buffer's end if it is not `NUL` terminated. Fix the issue by using `git__prefixncmp` instead. Add a test that verifies that we are unable to parse the encoding field if it's cut off by the supplied buffer length.

c2e3d8ef

2018-10-25T12:01:18

tests: add tests that exercise commit parsing We currently do not have any test suites dedicated to parsing commits from their raw representations. Add one based on `git_object__from_raw` to be able to test special cases more easily.

ee11d47e

2018-10-19T09:47:50

tag: fix out of bounds read when searching for tag message When parsing tags, we skip all unknown fields that appear before the tag message. This skipping is done by using a plain `strstr(buffer, "\n\n")` to search for the two newlines that separate tag fields from tag message. As it is not possible to supply a buffer length to `strstr`, this call may skip over the buffer's end and thus result in an out of bounds read. As `strstr` may return a pointer that is out of bounds, the following computation of `buffer_end - buffer` will overflow and result in an allocation of an invalid length. Fix the issue by using `git__memmem` instead. Add a test that verifies parsing the tag fails not due to the allocation failure but due to the tag having no message.

4c738e56

2018-10-19T09:44:14

tests: add tests that exercise tag parsing While the tests in object::tag::read exercises reading and parsing valid tags from the ODB, they barely try to verify that the parser fails in a sane way when parsing invalid tags. Create a new test suite object::tag::parse that directly exercise the parser by using `git_object__from_raw` and add various tests for valid and invalid tags.

83e8a6b3

2018-10-18T16:08:46

util: provide `git__memmem` function Unfortunately, neither the `memmem` nor the `strnstr` functions are part of any C standard but are merely extensions of C that are implemented by e.g. glibc. Thus, there is no standardized way to search for a string in a block of memory with a limited size, and using `strstr` is to be considered unsafe in case where the buffer has not been sanitized. In fact, there are some uses of `strstr` in exactly that unsafe way in our codebase. Provide a new function `git__memmem` that implements the `memmem` semantics. That is in a given haystack of `n` bytes, search for the occurrence of a byte sequence of `m` bytes and return a pointer to the first occurrence. The implementation chosen is the "Not So Naive" algorithm from [1]. It was chosen as the implementation is comparably simple while still being reasonably efficient in most cases. Preprocessing happens in constant time and space, searching has a time complexity of O(n*m) with a slightly sub-linear average case. [1]: http://www-igm.univ-mlv.fr/~lecroq/string/

bea65980

2018-10-25T11:21:14

Merge pull request #4851 from pks-t/pks/strtol-removal strtol removal

2e34efaa

2018-10-21T13:10:06

buf::oom tests: use custom allocator for oom failures Create a custom allocator for the `buf::oom` tests that will fail with out-of-memory errors in predictable ways. We were previously trying to guess the way that various allocators on various platforms would fail in a way such that `malloc`/`realloc` would return `NULL` (instead of aborting the application, or appearing suspicious to various instrumentation or static code analysis tools like valgrind.) Introduce a fake `malloc` and `realloc` that will return `NULL` on allocations requesting more than 100 bytes. Otherwise, we proxy to the default allocator. (It's important to use the _default_ allocator, not just call `malloc`, since the default allocator on Windows CI builds may be the debugging C runtime allocators which would not be compatible with a standard `malloc`.)

415a8ae9

2018-09-13T13:27:07

tests: don't run buf::oom on 32-bit systems On a 32-bit Linux systems, the value large enough to make malloc guarantee a failure is also large enough that valgrind considers it "fishy". Skip this test on those systems entirely.

7c791f3d

2018-10-20T20:25:51

Merge pull request #4852 from libgit2/ethomson/unc_paths Win32 path canonicalization refactoring

6cc14ae3

2018-10-20T20:22:04

Merge pull request #4840 from libgit2/cmn/validity-tree-from-unowned-index Check object existence when creating a tree from an index

a2f9f94b

2018-10-20T20:18:04

Merge branch 'issue-4203'

c79e6081

2018-10-20T19:08:16

checkout: fix test fixture missing objects The testrepo test fixture has an index file that's damaged, missing an object. The index previously had an entry of `src/index.c` with id 3161df8cbf3a006b4ef85be6497a0ea6bde98541, but that object was missing in the repository. This commit adds an object to the repository and updates the index to use that existing blob. Similarly, the index has an entry for `readme` with an id of 97328ac7e3bd0bcd3900cb3e7a624d71dd0df888. This can be restored from other test repositories. With these fixed, now the write tree from index tests can pass since they validate object existence.

da500cc6

2018-10-20T05:43:40

symlink tests: test symbolic links on windows Test updated symbolic link creation on Windows. Ensure that we emulate Git for Windows behavior. Ensure that when `core.symlinks=true` is set in a global configuration that new repositories are created without a `core.symlinks` setting, and that when `core.symlinks` is unset that `core.symlinks=false` in set in the repository. Further ensure that checkout honors the expected `core.symlinks` defaults on Windows.

3f0caa15

2018-10-20T02:49:49

repo::init tests: refactor global config path override Provide a function that allows tests to set up a bespoke global configuration path.

628dae8b

2018-10-19T03:14:35

tests: provide symlink support helper function

df1733de

2018-07-16T05:16:41

checkout tests: ensure readlink succeeds Don't try to use `link_size` as an index into a string if `p_readlink` returned <0. That will - obviously - fail and we'll write out of bounds.

8533c80d

2018-07-03T02:51:40

repo tests: ensure core.symlinks is set correctly Ensure that `core.symlinks` is set correctly. By default, it is unset, but it is explicitly set to `false` if the platform was detected to not support symlinks during repository initialization.

e4ac4000

2018-07-02T12:57:56

checkout tests: test symlinks based on support, not platform When testing whether symlinks are correctly checked out, examine the `core.symlinks` configuration option to determine if symlinks are supported in a repository, don't simply assume that Windows means that symbolic links are not supported. Further, when testing the expected default behavior of `core.symlinks`, test the filesystem's support to determine if symlinks are supported. Finally, ensure that `core.symlinks=true` fails on a system where symlinks are actually not supported. This aligns with the behavior of Git for Windows.

thodg/libgit2/tests

tests

Log