|
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.
|
|
|
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.
|
|
|
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.
|
|
|
ea19efc1
|
2018-10-18T15:08:56
|
|
util: fix out of bounds read in error message
When an integer that is parsed with `git__strntol32` is too big to fit
into an int32, we will generate an error message that includes the
actual string that failed to parse. This does not acknowledge the fact
that the string may either not be NUL terminated or alternative include
additional characters after the number that is to be parsed. We may thus
end up printing characters into the buffer that aren't the number or,
worse, read out of bounds.
Fix the issue by utilizing the `endptr` that was set by
`git__strntol64`. This pointer is guaranteed to be set to the first
character following the number, and we can thus use it to compute the
width of the number that shall be printed. Create a test to verify that
we correctly truncate the number.
|
|
|
16fd9ba9
|
2018-10-17T11:34:38
|
|
win32: more tests for `git_win32_remove_path`
|
|
|
b2e85f98
|
2018-10-17T08:48:43
|
|
win32: rename `git_win32__canonicalize_path`
The internal API `git_win32__canonicalize_path` is far, far too easily
confused with the internal API `git_win32_path_canonicalize`. The
former removes the namespace prefix from a path (eg, given
`\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given
`\\?\UNC\server\share`, it returns `\\server\share`). As such, rename
it to `git_win32_path_remove_namespace`.
`git_win32_path_canonicalize` remains unchanged.
|
|
|
39087ab8
|
2018-10-18T12:11:33
|
|
tests: core::strtol: test for some more edge-cases
Some edge cases were currently completely untested, e.g. parsing numbers
greater than INT64_{MIN,MAX}, truncating buffers by length and invalid
characters. Add tests to verify that the system under test performs as
expected.
|
|
|
8d7fa88a
|
2018-10-18T12:04:07
|
|
util: remove `git__strtol32`
The function `git__strtol32` can easily be misused when untrusted data
is passed to it that may not have been sanitized with trailing `NUL`
bytes. As all usages of this function have now been removed, we can
remove this function altogether to avoid future misuse of it.
|
|
|
68deb2cc
|
2018-10-18T11:37:10
|
|
util: remove unsafe `git__strtol64` function
The function `git__strtol64` does not take a maximum buffer length as
parameter. This has led to some unsafe usages of this function, and as
such we may consider it as being unsafe to use. As we have now
eradicated all usages of this function, let's remove it completely to
avoid future misuse.
|
|
1cbc9604
|
2018-09-28T10:57:50
|
|
config: add failing test for no newline after section header
|
|
|
814e7acb
|
2018-10-12T12:38:06
|
|
Merge pull request #4842 from nelhage/fuzz-config-memory
config: Port config_file_fuzzer to the new in-memory backend.
|
|
2d449a11
|
2018-10-09T02:42:14
|
|
config: Refactor `git_config_backend_from_string` to take a length
|
|
|
fbc0dcda
|
2018-10-08T13:01:23
|
|
index: add failing test for writing an invalid tree from an unowned index
When the index does not belong to any repository, we do not do any checks of the
target id going in as we cannot verify that it exists.
When we then write it out to a repository as a tree, we fail to perform the
object existance and type-matching check that we do in other code-paths. This
leads to being able to write trees which point to non-existent blobs even with
strict object creation enabled.
|
|
|
838a2f29
|
2018-10-07T12:00:48
|
|
Merge pull request #4828 from csware/git_futils_rmdir_r_failing
Add some more tests for git_futils_rmdir_r and some cleanup
|
|
|
0cd976c8
|
2018-10-07T12:00:06
|
|
Merge pull request #4830 from pks-t/pks/diff-stats-rename-common
diff_stats: use git's formatting of renames with common directories
|
|
|
a8d447f6
|
2018-10-05T20:13:34
|
|
Merge pull request #4837 from pks-t/cmn/reject-option-submodule-url-path
submodule: ignore path and url attributes if they look like options
|
|
|
ce8803a2
|
2018-10-05T20:03:38
|
|
Merge pull request #4836 from pks-t/pks/smart-packets
Smart packet security fixes
|
|
|
84d6f439
|
2018-10-05T19:53:22
|
|
Merge pull request #4832 from pks-t/pks/config-includes-null-deref
config_file: properly ignore includes without "path" value
|
|
|
4e0bdaa8
|
2018-10-05T11:42:00
|
|
submodule: add failing test for option-injection protection in url and path
|
|
|
ad273718
|
2018-10-04T10:32:07
|
|
tests: sanitize file hierarchy after running rmdir tests
Currently, we do not clean up after ourselves after tests in core::rmdir
have created new files in the directory hierarchy. This may leave stale
files and/or directories after having run tests, confusing subsequent
tests that expect a pristine test environment. Most importantly, it may
cause the test initialization to fail which expects being able to
re-create the testing hierarchy before each test in case where another
test hasn't cleaned up after itself.
Fix the issue by adding a cleanup function that removes the temporary
testing hierarchy after each test if it still exists.
|
|
e886ab46
|
2018-10-02T19:50:29
|
|
tests: Add some more tests for git_futils_rmdir_r
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
|
d06d4220
|
2018-10-05T10:56:02
|
|
config_file: properly ignore includes without "path" value
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.
|
|
|
bf662f7c
|
2018-10-05T10:55:29
|
|
tests: always unlink created config files
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.
|
|
|
dbb4a586
|
2018-10-05T10:27:33
|
|
tests: fix warning for implicit conversion of integer to pointer
GCC warns by default when implicitly converting integers to pointers or
the other way round, and commit fa48d2ea7 (vector: do not malloc
0-length vectors on dup, 2018-09-26) introduced such an implicit
conversion into our vector tests. While this is totally fine in this
test, as the pointer's value is never being used in the first place, we
can trivially avoid the warning by instead just inserting a pointer for
a variable allocated on the stack into the vector.
|
|
3f096ca5
|
2018-10-04T13:03:25
|
|
Fix comment style and update test code
|
|
|
e5090ee3
|
2018-10-04T11:19:28
|
|
diff_stats: use git's formatting of renames with common directories
In cases where a file gets renamed such that the directories containing
it previous and after the rename have a common prefix, then git will
avoid printing this prefix twice and instead format the rename as
"prefix/{old => new}". We currently didn't do anything like that, but
simply printed "prefix/old -> prefix/new".
Adjust our behaviour to instead match upstream. Adjust the test for this
behaviour to expect the new format.
|
|
|
3148efd2
|
2018-10-04T11:13:57
|
|
tests: verify diff stats with renames in subdirectory
Until now, we didn't have any tests that verified that our format for
renames in subdirectories is correct. While our current behaviour is no
different than for renames that do not happen with a common prefix
shared between old and new file name, we intend to change the format to
instead match the format that upstream git uses.
Add a test case for this to document our current behaviour and to show
how the next commit will change that format.
|
|
|
0b3dfbf4
|
2018-08-09T11:13:59
|
|
smart_pkt: reorder and rename parameters of `git_pkt_parse_line`
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.
|
|
|
a9f1ca09
|
2018-08-09T11:01:00
|
|
smart_pkt: fix buffer overflow when parsing "ok" packets
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)
|
|
|
bc349045
|
2018-08-09T10:38:10
|
|
smart_pkt: fix buffer overflow when parsing "ACK" packets
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.
|
|
|
365d2720
|
2018-10-03T15:39:40
|
|
tests: verify parsing logic for smart packets
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`.
|
|
8ab11dd5
|
2018-09-30T16:40:22
|
|
Fix issue with path canonicalization for Win32 paths
|
|
|
1621a37d
|
2018-09-29T13:22:59
|
|
Merge pull request #4812 from libgit2/ethomson/ci-refactor
CI: refactoring
|
|
0530d7d9
|
2018-09-28T18:04:23
|
|
Merge pull request #4767 from pks-t/pks/config-mem
In-memory configuration
|
|
|
2be39cef
|
2018-08-10T19:38:57
|
|
config: introduce new read-only in-memory backend
Now that we have abstracted away how to store and retrieve config
entries, it became trivial to implement a new in-memory backend by
making use of this. And thus we do so.
This commit implements a new read-only in-memory backend that can parse
a chunk of memory into a `git_config_backend` structure.
|
|
|
b944e137
|
2018-08-10T13:03:33
|
|
config: rename "config_file.h" to "config_backend.h"
The header "config_file.h" has a list of inline-functions to access the
contents of a config backend without directly messing with the struct's
function pointers. While all these functions are called
"git_config_file_*", they are in fact completely backend-agnostic and
don't care whether it is a file or not. Rename all the function to
instead be backend-agnostic versions called "git_config_backend_*" and
rename the header to match.
|
|
|
ba1cd495
|
2018-09-28T11:10:49
|
|
Merge pull request #4784 from tiennou/fix/warnings
Some warnings
|
|
|
367f6243
|
2018-09-28T11:04:06
|
|
Merge pull request #4803 from tiennou/fix/4802
index: release the snapshot instead of freeing the index
|
|
|
fa48d2ea
|
2018-09-26T19:15:35
|
|
vector: do not malloc 0-length vectors on dup
|
|
|
be4717d2
|
2018-09-18T12:12:06
|
|
path: fix "comparison always true" warning
|
|
|
e84914fd
|
2018-09-20T20:11:36
|
|
online::clone: free url and username before resetting
Before resetting the url and username, ensure that we free them in case
they were set by environment variables.
|
|
|
943181c2
|
2018-09-10T12:36:51
|
|
Revert "clar: introduce CLAR_XML option"
This reverts commit a2d73f5643814cddf90d5bf489332e14ada89ab8.
Using clar to propagate the XML settings was a mistake.
|
|
|
d17e67d0
|
2018-09-08T18:54:21
|
|
clar: iterate errors in report_all / report_errors
Instead of trying to have a clever iterator pattern that increments the
error number, just iterate over errors in the report errors or report
all functions as it's easier to reason about in this fashion.
|
|
|
e595eeb5
|
2018-08-27T01:06:37
|
|
ci: use more compatible strftime formats
Windows lacks %F and %T formats for strftime. Expand them to the
year/month/day and hour/minute/second formats, respectively.
|
|
|
b67a93ff
|
2018-09-04T14:00:49
|
|
clar: remove globals; error-check fprintf/fclose
Remove the global summary filename and file pointer; pass them in to the
summary functions as needed. Error check the results of buffered I/O
calls.
|
|
|
a2d73f56
|
2018-08-24T11:23:19
|
|
clar: introduce CLAR_XML option
Introduce a CLAR_XML option, to run the `ctest` commands with the new
`-r` flag to clar. Permitted values are `OFF`, `ON` and a directory to
write the XML test results to.
|
|
|
baa5c20d
|
2018-08-26T15:31:14
|
|
clar: accept a value for the summary filename
Accept an (optional) value for the summary filename. Continues to
default to summary.xml.
|
|
|
dbebcb04
|
2018-08-26T15:25:15
|
|
clar: don't use a variable named `time`
|
|
|
59f1e477
|
2018-07-27T23:00:09
|
|
Barebones JUnit XML output
|
|
|
3a9b9631
|
2018-07-26T23:02:34
|
|
Documentation
|
|
|
bf9fc126
|
2018-07-26T23:02:20
|
|
Isolate test reports
This makes it possible to keep track of every test status (even
successful ones), and their errors, if any.
|
|
|
90753a96
|
2018-08-26T15:11:21
|
|
clar: refactor explicitly run test behavior
Previously, supplying `-s` to explicitly enable some test(s) would run
the tests immediately from the argument parser. This forces us to set
up the entire clar environment (for example: sandboxing) before argument
parsing takes place.
Refactor the behavior of `-s` to add the explicitly chosen tests to a
list that is executed later. This untangles the argument parsing from
the setup lifecycle, allowing us to use the arguments to perform the
setup.
|
|
|
85eb2cb6
|
2018-08-26T11:33:42
|
|
Merge pull request #4727 from libgit2/cmn/null-oid-existing-tree
tree: accept null ids in existing trees when updating
|
|
|
50186ce8
|
2018-08-26T11:26:45
|
|
Merge pull request #4374 from pks-t/pks/pack-file-verify
Pack file verification
|
|
|
fd7ab1d7
|
2018-08-24T09:47:09
|
|
Merge pull request #4776 from pks-t/pks/test-index-invalid-filemode
tests: verify adding index conflicts with invalid filemodes fails
|
|
|
503af775
|
2018-08-24T10:08:09
|
|
Merge pull request #4769 from tiennou/fix/worktree-unlock
worktree: unlock should return 1 when the worktree isn't locked
|
|
|
3a1f5df8
|
2018-08-24T09:15:29
|
|
tests: verify adding index conflicts with invalid filemodes fails
Commit 581d5492f (Fix leak in index.c, 2018-08-16) was fixing a memory
leak in our code adding conflicts to the index when the added index
entries have an invalid file mode. The memory leak was previously
undiscovered as there are no tests covering this scenario, which is now
being added by this commit.
|
|
|
cada553c
|
2018-08-19T15:54:10
|
|
Merge pull request #4754 from libgit2/ethomson/threads
threads::diff: use separate git_repository objects
|
|
|
2afd0185
|
2018-08-19T12:57:29
|
|
threads::iterator: use separate repository objects
Our thread policies state that we cannot re-use the `git_repository`
across threads. Our tests cannot deviate from that.
Courtesy of Ximin Luo, https://github.com/infinity0:
https://github.com/libgit2/libgit2/issues/4753#issuecomment-412247757
|
|
|
59c2e70e
|
2018-08-17T00:51:51
|
|
worktree: unlock should return 1 when the worktree isn't locked
The documentation states that git_worktree_unlock returns 0 on success,
and 1 on success if the worktree wasn't locked. Turns out we were
returning 0 in any of those cases.
|
|
|
6698e056
|
2018-08-14T04:22:14
|
|
Fix the test and comment.
|
|
|
f1409500
|
2018-08-14T03:54:01
|
|
Write a test.
|
|
|
d1919485
|
2018-08-05T11:01:14
|
|
threads::diff: use separate git_repository objects
Our thread policies state that we cannot re-use the `git_repository`
across threads. Our tests cannot deviate from that.
|
|
|
f00db9ed
|
2018-07-27T12:00:37
|
|
tree: rename from_tree to validate and clarify the tree in the test
|
|
|
219512e7
|
2018-07-20T14:14:16
|
|
buf tests: allocate a smaller size for the oom
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.
|
|
|
ce798b25
|
2018-07-04T10:56:56
|
|
tests: simplify cmake test configuration
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.
|
|
|
d285de73
|
2018-07-20T21:52:24
|
|
push tests: deeply free the specs
Don't just free the spec vector, also free the specs themselves.
|
|
|
dad99881
|
2018-07-20T21:51:36
|
|
push tests: deeply free the push status
Don't just free the push status structure, actually free the strings that were
strdup'd into the struct as well.
|
|
|
0652abaa
|
2018-07-20T12:56:49
|
|
Merge pull request #4702 from tiennou/fix/coverity
Assorted Coverity fixes
|
|
|
2dff7e28
|
2018-07-18T21:04:13
|
|
tree: accept null ids in existing trees when updating
When we add entries to a treebuilder we validate them. But we validate even
those that we're adding because they exist in the base tree. This disables
using the normal mechanisms on these trees, even to fix them.
Keep track of whether the entry we're appending comes from an existing tree and
bypass the name and id validation if it's from existing data.
|
|
|
e1a4a8eb
|
2018-06-25T11:58:34
|
|
cmake: enforce C90 standard
While the aim of libgit2 was to conform to C90 code, we never instructed
the compiler to enforce C90 compliance. Thus, quite a few violations
were able to get into our code base, which have been removed with the
previous commits. As we are now able to build libgit2 with C90 enforced,
we can set the C_STANDARD property for our own build targets.
Note that we explicitly avoid setting the C standard for our third-party
dependencies. At least the zlib target does not build with C90 enforced,
and we do not want to fix them by deviating from upstream. Thus we
simply enforce no standard for them.
|
|
|
c13e56f9
|
2018-06-25T14:12:53
|
|
cmake: distinguish internal and system include directories
While we want to enforce strict C90 mode, this may cause issues with
system provided header files which are themselves not strictly
conforming. E.g. if a system header has C++ style comments, a compiler
in strict C90 mode would produce an error and abort the build. As the
user most likely doesn't want to change the system header, this would
completely break the build on such systems. One example of this is
mbedtls, which provides such header files.
The problem can be worked around by distinguishing between
system-provided and project-provided include directories. When adding
include directories via "-isystem" instead of "-I", the compiler will
skip certain checks and print out less warnings. To use system includes,
we can simply add the "SYSTEM" flag to CMake's `INCLUDE_DIRECTORIES` and
`TARGET_INCLUDE_DIRECTORIES` functions. Note that we have to split the
include directories into two variables because of this, as we definitely
still want to check for all warnings produced by our own header files.
|
|
|
9994cd3f
|
2018-06-25T11:56:52
|
|
treewide: remove use of C++ style comments
C++ style comment ("//") are not specified by the ISO C90 standard and
thus do not conform to it. While libgit2 aims to conform to C90, we did
not enforce it until now, which is why quite a lot of these
non-conforming comments have snuck into our codebase. Do a tree-wide
conversion of all C++ style comments to the supported C style comments
to allow us enforcing strict C90 compliance in a later commit.
|
|
|
6dfc8bc2
|
2018-07-09T23:10:05
|
|
Merge pull request #4719 from pks-t/pks/delta-oob
Delta OOB access
|
|
|
89091d36
|
2018-07-06T20:24:21
|
|
tests: fix a relative pathname issue
The path given to `git_index_add_bypath` is relative to the root of the
repository. That `describe/file` path is relative to the root of the
sandbox directory, hence if I add the missing `cl_git_pass` I rightfully
get an error that `$SANDBOX/describe/describe/file doesn't exist`.
The path is thus changed to be made relative to the repository, which
makes the failure go away and "restore" the test.
|
|
|
8455a270
|
2018-07-01T12:04:27
|
|
tests: add missing cl_git_pass to tests
Reported by Coverity, CID 1393678-1393697.
|
|
|
17bd3b96
|
2018-06-19T20:15:49
|
|
tests: mailmap/parsing: add a missing cl_git_pass
Reported by Coverity, CID 1393483
|
|
|
f4633791
|
2018-07-06T12:36:05
|
|
Merge pull request #4687 from tiennou/fix/4672
patch_parse: populate line numbers while parsing diffs
|
|
|
f2a1cece
|
2018-07-06T11:25:47
|
|
Merge pull request #4686 from tiennou/fix/more-worktree-from-bare
Fix git_worktree_validate failing on bare repositories
|
|
|
8a00de08
|
2018-07-06T10:47:06
|
|
Merge pull request #4699 from nelhage/fetch-null-dst
git_refspec_transform: Handle NULL dst
|
|
|
c43658f6
|
2018-06-30T13:24:23
|
|
Merge pull request #4536 from libgit2/ethomson/index_dirty
Add a "dirty" state to the index when it has unsaved changes
|
|
|
ff8edac9
|
2018-06-29T16:18:36
|
|
formatting fix
|
|
|
bfa1f022
|
2018-06-22T19:17:08
|
|
settings: optional unsaved index safety
Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause
commands that reload the on-disk index to fail if the current
`git_index` has changed that have not been saved. This will prevent
users from - for example - adding a file to the index then calling a
function like `git_checkout` and having that file be silently removed
from the index since it was re-read from disk.
Now calls that would re-read the index will fail if the index is
"dirty", meaning changes have been made to it but have not been written.
Users can either `git_index_read` to discard those changes explicitly,
or `git_index_write` to write them.
|