|
31541e5f
|
2019-12-03T19:24:59
|
|
path: protect NTFS everywhere
Enable core.protectNTFS by default everywhere and in every codepath, not
just on checkout.
|
|
|
dbee08cf
|
2019-12-03T19:17:41
|
|
test: ensure we can't add a protected path
Test that when we enable core.protectNTFS that we cannot add
platform-specific invalid paths to the index.
|
|
|
b437de92
|
2019-12-03T18:57:16
|
|
test: ensure treebuilder validate new protection rules
Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
enabled for using the treebuilder when core.protectNTFS is set.
|
|
4bae85c5
|
2019-09-18T16:33:18
|
|
path: also guard `.gitmodules` against NTFS Alternate Data Streams
We just safe-guarded `.git` against NTFS Alternate Data Stream-related
attack vectors, and now it is time to do the same for `.gitmodules`.
Note: In the added regression test, we refrain from verifying all kinds
of variations between short names and NTFS Alternate Data Streams: as
the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it
is enough to test one in order to know that all of them are guarded
against.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
3595e237
|
2019-09-18T14:32:05
|
|
Disallow NTFS Alternate Data Stream attacks, even on Linux/macOS
A little-known feature of NTFS is that it offers to store metadata in
so-called "Alternate Data Streams" (inspired by Apple's "resource
forks") that are copied together with the file they are associated with.
These Alternate Data Streams can be accessed via `<file name>:<stream
name>:<stream type>`.
Directories, too, have Alternate Data Streams, and they even have a
default stream type `$INDEX_ALLOCATION`. Which means that `abc/` and
`abc::$INDEX_ALLOCATION/` are actually equivalent.
This is of course another attack vector on the Git directory that we
definitely want to prevent.
On Windows, we already do this incidentally, by disallowing colons in
file/directory names.
While it looks as if files'/directories' Alternate Data Streams are not
accessible in the Windows Subsystem for Linux, and neither via
CIFS/SMB-mounted network shares in Linux, it _is_ possible to access
them on SMB-mounted network shares on macOS.
Therefore, let's go the extra mile and prevent this particular attack
_everywhere_. To keep things simple, let's just disallow *any* Alternate
Data Stream of `.git`.
This is libgit2's variant of CVE-2019-1352.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
ee3dbe12
|
2019-12-03T18:56:31
|
|
test: ensure index adds validate new protection rules
Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
enabled for adding to the index when core.protectNTFS is set.
|
|
|
ca8a4cd3
|
2019-09-18T15:25:02
|
|
Protect against 8.3 "short name" attacks also on Linux/macOS
The Windows Subsystem for Linux (WSL) is getting increasingly popular,
in particular because it makes it _so_ easy to run Linux software on
Windows' files, via the auto-mounted Windows drives (`C:\` is mapped to
`/mnt/c/`, no need to set that up manually).
Unfortunately, files/directories on the Windows drives can be accessed
via their _short names_, if that feature is enabled (which it is on the
`C:` drive by default).
Which means that we have to safeguard even our Linux users against the
short name attacks.
Further, while the default options of CIFS/SMB-mounts seem to disallow
accessing files on network shares via their short names on Linux/macOS,
it _is_ possible to do so with the right options.
So let's just safe-guard against short name attacks _everywhere_.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
97dc50ac
|
2019-09-18T15:08:56
|
|
cl_git_fail: do not report bogus error message
When we expect a checkout operation to fail, but it succeeds, we
actually do not want to see the error messages that were generated in
the meantime for errors that were handled gracefully by the code (e.g.
when an object could not be found in a pack: in this case, the next
backend would have been given a chance to look up the object, and
probably would have found it because the checkout succeeded, after all).
Which means that in the specific case of `cl_git_fail()`, we actually
want to clear the global error state _after_ evaluating the command: we
know that any still-available error would be bogus, seeing as the
command succeeded (unexpectedly).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
70edf887
|
2019-12-03T19:01:00
|
|
test: improve badname verification test
The name of the `add_invalid_filename` function suggests that we
_want_ to add an invalid filename. Rename the function to show that
we expect to _fail_ to add the invalid filename.
|
|
|
ba6e2bfb
|
2019-12-03T18:49:23
|
|
test: improve badname verification test
The name of the `write_invalid_filename` function suggests that we
_want_ to write an invalid filename. Rename the function to show that
we expect to _fail_ to write the invalid filename.
|
|
5fff24ea
|
2018-06-05T16:45:23
|
|
tests: status::ignore: fix style of a test
|
|
|
446b85c3
|
2018-06-05T16:12:58
|
|
ignore: fix negative leading directory rules unignoring subdirectory files
When computing whether a file is ignored, we simply search for the first
matching rule and return whether it is a positive ignore rule (the file
is really ignored) or whether it is a negative ignore rule (the file is
being unignored). Each rule has a set of flags which are being passed to
`fnmatch`, depending on what kind of rule it is. E.g. in case it is a
negative ignore we add a flag `GIT_ATTR_FNMATCH_NEGATIVE`, in case it
contains a glob we set the `GIT_ATTR_FNMATCH_HASGLOB` flag.
One of these flags is the `GIT_ATTR_FNMATCH_LEADINGDIR` flag, which is
always set in case the pattern has a trailing "/*" or in case the
pattern is negative. The flag causes the `fnmatch` function to return a
match in case a string is a leading directory of another, e.g. "dir/"
matches "dir/foo/bar.c". In case of negative patterns, this is wrong in
certain cases.
Take the following simple example of a gitignore:
dir/
!dir/
The `LEADINGDIR` flag causes "!dir/" to match "dir/foo/bar.c", and we
correctly unignore the directory. But take this example:
*.test
!dir/*
We expect everything in "dir/" to be unignored, but e.g. a file in a
subdirectory of dir should be ignored, as the "*" does not cross
directory hierarchies. With `LEADINGDIR`, though, we would just see that
"dir/" matches and return that the file is unignored, even if it is
contained in a subdirectory. Instead, we want to ignore leading
directories here and check "*.test". Afterwards, we have to iterate up
to the parent directory and do the same checks.
To fix the issue, disallow matching against leading directories in
gitignore files. This can be trivially done by just adding the
`GIT_ATTR_FNMATCH_NOLEADINGDIR` to the spec passed to
`git_attr_fnmatch__parse`. Due to a bug in that function, though, this
flag is being ignored for negative patterns, which is fixed in this
commit, as well. As a last fix, we need to ignore rules that are
supposed to match a directory when our path itself is a file.
All together, these changes fix the described error case.
|
|
|
6cb9cd53
|
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
|
|
|
a628c2e8
|
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.
|
|
|
af9692ba
|
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.
|
|
|
d04c1aa0
|
2018-11-28T13:36:47
|
|
config: fix adding files if their parent directory is a file
When we try to add a configuration file with `git_config_add_file_ondisk`, we
treat nonexisting files as empty. We do this by performing a stat call, ignoring
ENOENT errors. This works just fine in case the file or any of its parents
simply does not exist, but there is also the case where any of the parent
directories is not a directory, but a file. So e.g. trying to add a
configuration file "/dev/null/.gitconfig" will fail, as `errno` will be ENOTDIR
instead of ENOENT.
Catch ENOTDIR in addition to ENOENT to fix the issue. Add a test that verifies
we are able to add configuration files with such an invalid path file just fine.
|
|
19cde48c
|
2018-12-14T14:29:36
|
|
annotated_commit: add failing test for looking up from annotated tag
|
|
|
6daeb4fb
|
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.
|
|
98a6d9d5
|
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
```
|
|
|
0952278f
|
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.
(cherry picked from commit dbb4a5866fcbb121000a705e074f679445d6916b)
|
|
ef7d7def
|
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.
(cherry picked from commit 59c2e70eeee8b2bae79d05060599114a5f6d737a)
|
|
f4a7652a
|
2018-08-14T04:22:14
|
|
Fix the test and comment.
(cherry picked from commit 6698e0562d0f782903f28c224c879da7c2abf674)
|
|
|
ef523712
|
2018-08-14T03:54:01
|
|
Write a test.
(cherry picked from commit f140950066cf2989912e18ad92ec088f624b8bf2)
|
|
|
b8844566
|
2018-07-27T12:00:37
|
|
tree: rename from_tree to validate and clarify the tree in the test
(cherry picked from commit f00db9ed67423b04976f8d20b0de2ee1fb7c3993)
|
|
|
ebb0e37e
|
2018-09-26T19:15:35
|
|
vector: do not malloc 0-length vectors on dup
(cherry picked from commit fa48d2ea7d2d5dc9620e5c9f05ba8d788775582b)
|
|
|
c37c6ed8
|
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.
(cherry picked from commit 2dff7e282da77f6b791e843ec267d9ddecabc187)
|
|
|
a051bce7
|
2018-06-18T20:37:18
|
|
patch_parse: populate line numbers while parsing diffs
(cherry picked from commit f9e28026753f7b6c871a160ad584b2dc2639d30f)
|
|
|
c62c6379
|
2018-04-20T08:38:50
|
|
worktree: a worktree can be made from a bare repository
|
|
|
ab0d9fb2
|
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/
(cherry picked from commit 83e8a6b36acc67f2702cbbc7d4e334c7f7737719)
|
|
|
c8e94f84
|
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.
(cherry picked from commit ea19efc19fa683d632af3e172868bc4350724813)
|
|
|
55f4f235
|
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.
(cherry picked from commit 39087ab8ef77004c9f3b8984c38a834a6cb238bc)
|
|
|
e2e7a9cb
|
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.
(cherry picked from commit 8d7fa88a9d5011b653035497b0f523e0f177b6a6)
|
|
|
6b2b63e5
|
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.
(cherry picked from commit 68deb2cc80ef19bf3a1915c26b5308b283a6d69a)
|
|
|
54c02f26
|
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.
(cherry picked from commit e84914fd30edc6702e368c8ccfc77dc5607c213c)
|
|
|
27469ed3
|
2018-07-20T21:52:24
|
|
push tests: deeply free the specs
Don't just free the spec vector, also free the specs themselves.
(cherry picked from commit d285de73f9a09bc841b329267d1f61b9c03a7b68)
|
|
|
c8826499
|
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.
(cherry picked from commit dad9988121521ccc2ffff39299ca98dba160b857)
|
|
|
886a0842
|
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.
(cherry picked from commit 943181c2efe20b705aa40d30197693e7a4c1d0ac)
|
|
|
f5074e28
|
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.
(cherry picked from commit d17e67d08d6e73dbf0daeae5049f92a38c2d8bb6)
|
|
|
f56e1e70
|
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.
(cherry picked from commit e595eeb5ab88142b97798ed65e651de6560515e9)
|
|
|
f42a251c
|
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.
(cherry picked from commit b67a93ff81e2fbfcf9ebb52dd15db9aa4e9ca708)
|
|
|
a539205e
|
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.
(cherry picked from commit a2d73f5643814cddf90d5bf489332e14ada89ab8)
|
|
|
a133caa2
|
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.
(cherry picked from commit baa5c20d0815441cac2d2135d2b0190cb543e637)
|
|
|
8b68cb23
|
2018-08-26T15:25:15
|
|
clar: don't use a variable named `time`
(cherry picked from commit dbebcb04b42047df0d52ad3515077a134c5b7da7)
|
|
|
4c48aeb5
|
2018-07-27T23:00:09
|
|
Barebones JUnit XML output
(cherry picked from commit 59f1e477f772c73c76bc654a0853fdcf491a32a7)
|
|
|
564ab8ae
|
2018-07-26T23:02:34
|
|
Documentation
(cherry picked from commit 3a9b96311d6f0ff364c6417cf3aab7c9745b18d4)
|
|
|
698b0928
|
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.
(cherry picked from commit bf9fc126709af948c2a324ceb1b2696046c91cfe)
|
|
|
57f86c22
|
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.
(cherry picked from commit 90753a96515f85e2d0e79a16d3a06ba5b363c68e)
|
|
|
f2087fc7
|
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.
(cherry picked from commit 219512e7989340d9efae8480fb79c08b91724014)
|
|
|
373bf31f
|
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.
(cherry picked from commit ce798b256b071f57bfd62664626c10339b3e36f7)
|
|
|
34597d10
|
2018-10-05T11:42:00
|
|
submodule: add failing test for option-injection protection in url and path
|
|
|
614c266d
|
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.
(cherry picked from commit d06d4220eec035466d1a837972a40546b8904330)
|
|
|
aa220b0f
|
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.
(cherry picked from commit bf662f7cf8daff2357923446cf9d22f5d4b4a66b)
|
|
|
7e3cd611
|
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.
(cherry picked from commit 0b3dfbf425d689101663341beb94237614f1b5c2)
|
|
|
319f0c03
|
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)
(cherry picked from commit a9f1ca09178af0640963e069a2142d5ced53f0b4)
|
|
|
0599c267
|
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.
(cherry picked from commit bc349045b1be8fb3af2b02d8554483869e54d5b8)
|
|
|
bd069448
|
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`.
(cherry picked from commit 365d2720c1a5fc89f03fd85265c8b45195c7e4a8)
|
|
|
9844d38b
|
2018-06-29T09:11:02
|
|
delta: fix out-of-bounds read of delta
When computing the offset and length of the delta base, we repeatedly
increment the `delta` pointer without checking whether we have advanced
past its end already, which can thus result in an out-of-bounds read.
Fix this by repeatedly checking whether we have reached the end. Add a
test which would cause Valgrind to produce an error.
Reported-by: Riccardo Schirone <rschiron@redhat.com>
Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
|
|
|
3f461902
|
2018-06-29T07:45:18
|
|
delta: fix sign-extension of big left-shift
Our delta code was originally adapted from JGit, which itself adapted it
from git itself. Due to this heritage, we inherited a bug from git.git
in how we compute the delta offset, which was fixed upstream in
48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As
explained by Linus:
Shifting 'unsigned char' or 'unsigned short' left can result in sign
extension errors, since the C integer promotion rules means that the
unsigned char/short will get implicitly promoted to a signed 'int' due to
the shift (or due to other operations).
This normally doesn't matter, but if you shift things up sufficiently, it
will now set the sign bit in 'int', and a subsequent cast to a bigger type
(eg 'long' or 'unsigned long') will now sign-extend the value despite the
original expression being unsigned.
One example of this would be something like
unsigned long size;
unsigned char c;
size += c << 24;
where despite all the variables being unsigned, 'c << 24' ends up being a
signed entity, and will get sign-extended when then doing the addition in
an 'unsigned long' type.
Since git uses 'unsigned char' pointers extensively, we actually have this
bug in a couple of places.
In our delta code, we inherited such a bogus shift when computing the
offset at which the delta base is to be found. Due to the sign extension
we can end up with an offset where all the bits are set. This can allow
an arbitrary memory read, as the addition in `base_len < off + len` can
now overflow if `off` has all its bits set.
Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned
integer again. Add a test with a crafted delta that would actually
succeed with an out-of-bounds read in case where the cast wouldn't
exist.
Reported-by: Riccardo Schirone <rschiron@redhat.com>
Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
|
|
|
35865117
|
2018-06-06T09:23:01
|
|
tests: submodule: do not rely on config iteration order
The test submodule::lookup::duplicated_path, which tries to verify that
we detect submodules with duplicated paths, currently relies on the
gitmodules file of "submod2_target". While this file has two gitmodules
with the same path, one of these gitmodules has an empty name and thus
does not pass `git_submodule_name_is_valid`. Because of this, the test
is in fact dependent on the iteration order in which we process the
submodules. In fact the "valid" submodule comes first, the "invalid"
submodule will cause the desired error. In fact the "invalid" submodule
comes first, it will be skipped due to its name being invalid, and we
will not see the desired error. While this works on the master branch
just right due to the refactoring of our config code, where iteration
order is now deterministic, this breaks on all older maintenance
branches.
Fix the issue by simply using `cl_git_rewritefile` to rewrite the
gitmodules file. This greatly simplifies the test and also makes the
intentions of it much clearer.
|
|
|
7392799d
|
2018-05-30T08:35:06
|
|
submodule: detect duplicated submodule paths
When loading submodule names, we build a map of submodule paths and
their respective names. While looping over the configuration keys,
we do not check though whether a submodule path was seen already. This
leads to a memory leak in case we have multiple submodules with the same
path, as we just overwrite the old value in the map in that case.
Fix the error by verifying that the path to be added is not yet part of
the string map. Git does not allow to have multiple submodules for a
path anyway, so we now do the same and detect this duplication,
reporting it to the user.
|
|
|
f2e5c092
|
2018-04-27T15:31:43
|
|
cmake: remove now-useless LIBGIT2_LIBDIRS handling
With the recent change of always resolving pkg-config libraries to their
full path, we do not have to manage the LIBGIT2_LIBDIRS variable
anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp,
which is a CMake-style library target and can thus be resolved by CMake
automatically.
Remove the variable to simplify our build system a bit.
|
|
96329606
|
2018-03-11T15:35:56
|
|
worktree: Read worktree specific reflog for HEAD
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
2569056d
|
2018-04-04T21:29:03
|
|
typo: Fixed a trivial typo in test function.
|
|
|
16b62dd4
|
2018-04-04T21:28:31
|
|
diff: Add missing GIT_DELTA_TYPECHANGE -> 'T' mapping.
This adds the 'T' status character to git_diff_status_char() for diff
entries that change type.
|
|
|
07011e60
|
2018-04-12T13:32:27
|
|
revwalk: fix uninteresting revs sometimes not limiting graphwalk
When we want to limit our graphwalk, we use the heuristic of checking
whether the newest limiting (uninteresting) revision is newer than the
oldest interesting revision. We do so by inspecting whether the first
item's commit time of the user-supplied list of revisions is newer than
the last added interesting revision. This is wrong though, as the user
supplied list is in no way guaranteed to be sorted by increasing commit
dates. This could lead us to abort the revwalk early before applying all
relevant limiting revisions, outputting revisions which should in fact
have been hidden.
Fix the heuristic by instead checking whether _any_ of the limiting
commits was made earlier than the last interesting commit. Add a test.
|
|
|
0f88adb6
|
2018-02-08T12:36:47
|
|
Submodule API should report .gitmodules parse errors
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
|
b6623be0
|
2018-04-10T23:49:44
|
|
tests: ensure worktrees' head have owners too
|
|
|
e2a80124
|
2018-04-10T21:16:43
|
|
refs: preserve the owning refdb when duping reference
This fixes a segfault in git_reference_owner on references returned from git_reference__read_head and git_reference_dup ones.
|
|
e9ee7bd0
|
2018-04-19T15:21:52
|
|
fixed stack smashing due to wrong size of struct stat on the stack
on 32-bit systems with 64-bit file descriptor offsets enabled
(added -D_FILE_OFFSET_BITS=64 when compiling the test suite)
|
|
|
b260fdc8
|
2018-04-06T12:24:10
|
|
attr_file: fix handling of directory patterns with trailing spaces
When comparing whether a path matches a directory rule, we pass the
both the path and directory name to `fnmatch` with
`GIT_ATTR_FNMATCH_DIRECTORY` being set. `fnmatch` expects the pattern to
contain no trailing directory '/', which is why we try to always strip
patterns of trailing slashes. We do not handle that case correctly
though when the pattern itself has trailing spaces, causing the match to
fail.
Fix the issue by stripping trailing spaces and tabs for a rule previous
to checking whether the pattern is a directory pattern with a trailing
'/'. This replaces the whitespace-stripping in our ignore file parsing
code, which was stripping whitespaces too late. Add a test to catch
future breakage.
|
|
|
a714e836
|
2018-04-06T10:39:16
|
|
transports: local: fix assert when fetching into repo with symrefs
When fetching into a repository which has symbolic references via the
"local" transport we run into an assert. The assert is being triggered
while we negotiate the packfile between the two repositories. When
hiding known revisions from the packbuilder revwalk, we unconditionally
hide all references of the local refdb. In case one of these references
is a symbolic reference, though, this means we're trying to hide a
`NULL` OID, which triggers the assert.
Fix the issue by only hiding OID references from the revwalk. Add a test
to catch this issue in the future.
|
|
|
ed95962b
|
2018-05-24T21:58:40
|
|
path: hand-code the zero-width joiner as UTF-8
|
|
|
cfed1be8
|
2018-05-24T20:28:36
|
|
submodule: plug leaks from the escape detection
|
|
|
be20626a
|
2018-05-22T20:37:23
|
|
checkout: change symlinked .gitmodules file test to expect failure
When dealing with `core.proectNTFS` and `core.protectHFS` we do check
against `.gitmodules` but we still have a failing test as the non-filesystem
codepath does not check for it.
|
|
|
aa003557
|
2018-05-22T16:13:47
|
|
path: reject .gitmodules as a symlink
Any part of the library which asks the question can pass in the mode to have it
checked against `.gitmodules` being a symlink.
This is particularly relevant for adding entries to the index from the worktree
and for checking out files.
|
|
f907a6f5
|
2018-05-18T15:16:53
|
|
path: hide the dotgit file functions
These can't go into the public API yet as we don't want to introduce API or ABI
changes in a security release.
|
|
|
26b3cec0
|
2018-05-16T15:42:08
|
|
path: add a function to detect an .gitmodules file
Given a path component it knows what to pass to the filesystem-specific
functions so we're protected even from trees which try to use the 8.3 naming
rules to get around us matching on the filename exactly.
The logic and test strings come from the equivalent git change.
|
|
|
916af8ea
|
2018-05-14T16:03:15
|
|
submodule: also validate Windows-separated paths for validity
Otherwise we would also admit `..\..\foo\bar` as a valid path and fail to
protect Windows users.
Ideally we would check for both separators without the need for the copied
string, but this'll get us over the RCE.
|
|
|
e6c757a7
|
2018-04-30T13:47:15
|
|
submodule: ignore submodules which include path traversal in their name
If the we decide that the "name" of the submodule (i.e. its path inside
`.git/modules/`) is trying to escape that directory or otherwise trick us, we
ignore the configuration for that submodule.
This leaves us with a half-configured submodule when looking it up by path, but
it's the same result as if the configuration really were missing.
The name check is potentially more strict than it needs to be, but it lets us
re-use the check we're doing for the checkout. The function that encapsulates
this logic is ready to be exported but we don't want to do that in a security
release so it remains internal for now.
|
|
|
6442f1f1
|
2018-04-30T13:03:44
|
|
submodule: add a failing test for a submodule escaping .git/modules
We should pretend such submdules do not exist as it can lead to RCE.
|
|
|
c7cac088
|
2018-05-22T15:21:08
|
|
path: accept the name length as a parameter
We may take in names from the middle of a string so we want the caller to let us
know how long the path component is that we should be checking.
|
|
|
ed357be1
|
2018-05-22T14:16:45
|
|
checkout: add a failing test for refusing a symlinked .gitmodules
We want to reject these as they cause compatibility issues and can lead to git
writing to files outside of the repository.
|
|
|
a52b4c51
|
2018-03-23T09:59:46
|
|
odb: fix writing to fake write streams
In commit 7ec7aa4a7 (odb: assert on logic errors when writing objects,
2018-02-01), the check for whether we are trying to overflowing the fake
stream buffer was changed from returning an error to raising an assert.
The conversion forgot though that the logic around `assert`s are
basically inverted. Previously, if the statement
stream->written + len > steram->size
evaluated to true, we would return a `-1`. Now we are asserting that
this statement is true, and in case it is not we will raise an error. So
the conversion to the `assert` in fact changed the behaviour to the
complete opposite intention.
Fix the assert by inverting its condition again and add a regression
test.
|
|
|
904307af
|
2018-03-23T09:58:57
|
|
tests: add tests for the mempack ODB backend
Our mempack ODB backend has no test coverage at all right now. Add a
simple test suite to at least have some coverage of the most basic
operations on the ODB.
|
|
|
54bf4d14
|
2018-03-20T07:47:27
|
|
online tests: update auth for bitbucket test
Update the settings to use a specific read-only token for accessing our
test repositories in Bitbucket.
|
|
|
9108959a
|
2018-03-14T15:03:35
|
|
buf: add tests for percent decoding
|
|
30333e82
|
2018-02-28T13:00:04
|
|
Update tests
|
|
|
03c58778
|
2018-03-19T09:20:35
|
|
online::clone: skip creds fallback test
At present, we have three online tests against bitbucket: one which
specifies the credentials in the payload, one which specifies the
correct credentials in the URL and a final one that specifies the
incorrect credentials in the URL. Bitbucket has begun responding to the
latter test with a 403, which causes us to fail.
Break these three tests into separate tests so that we can skip the
latter until this is resolved on Bitbucket's end or until we can change
the test to a different provider.
|
|
|
a554d588
|
2018-02-28T12:21:08
|
|
tree: initialize the id we use for testing submodule insertions
Instead of laving it uninitialized and relying on luck for it to be non-zero,
let's give it a dummy hash so we make valgrind happy (in this case the hash
comes from `sha1sum </dev/null`.
|
|
|
275693e2
|
2018-02-20T12:45:40
|
|
checkout test: ensure workdir mode is simplified
Ensure that when examining the working directory for checkout that the
mode is correctly simplified. Git only pays attention to whether a file
is executable or not. When examining a working directory, we should
coalesce modes in the working directory to either `0755` (indicating
that a file is executable) or `0644` (indicating that it is not).
Test this by giving the file an exotic mode, and ensuring that when
checkout out a branch that changes the file's contents, that we do not
have a checkout conflict.
|
|
|
ec96db57
|
2018-02-20T00:32:38
|
|
checkout test: add core.filemode checkout tests
Add two tests for filemode.
The first ensures that `core.filemode=true` is honored: if we have
changed the filemode such that a file that _was_ executable (mode 0755)
is now executable (mode 0644) and we go to check out a branch that has
otherwise changed the contents of the file, then we should raise a
checkout conflict for that file.
The second ensures that `core.filemode=false` is honored: in the same
situation, we set a file that was executable to be non-executable, and
check out the branch that changes the contents of the file. However,
since `core.filemode` is false, we do not detect the filemode change.
We run these tests on both operating systems that obey `core.filemode`
(eg, POSIX) and those that have no conception of filemode (eg, Win32).
This ensures that `core.filemode` is always honored, as it is a cache of
the underlying filesystem's settings. This ensures that we do not
make assumptions based on the operating system, and honor the
configuration setting even if it were misconfigured.
|
|
|
18d9c847
|
2018-02-20T00:32:38
|
|
testrepo: add new branch
Add a new branch to the `testrepo` repository, where the `README` file
has changed to executable. This branch enables typechange tests between
the new `executable` branch and `master`.
|
|
|
894ccf4b
|
2018-02-20T16:14:54
|
|
Merge pull request #4535 from libgit2/ethomson/checkout_typechange_with_index_and_wd
checkout: when examining index (instead of workdir), also examine mode
|
|
|
4e4771dc
|
2018-02-19T22:10:44
|
|
checkout test: further ensure workdir perms are updated
When both the index _and_ the working directory has changed
permissions on a file permissions on a file - but only the permissions,
such that the contents of the file are identical - ensure that
`git_checkout` updates the permissions to match the checkout target.
|
|
|
8858a684
|
2018-02-19T22:09:27
|
|
checkout test: ensure workdir perms are updated
When the working directory has changed permissions on a file - but only
the permissions, such that the contents of the file are identical -
ensure that `git_checkout` updates the permissions to match the checkout
target.
|
|
|
ce7080a0
|
2018-02-20T10:38:27
|
|
diff_tform: fix rename detection with rewrite/delete pair
A rewritten file can either be classified as a modification of its
contents or of a delete of the complete file followed by an addition of
the new content. This distinction becomes important when we want to
detect renames for rewrites. Given a scenario where a file "a" has been
deleted and another file "b" has been renamed to "a", this should be
detected as a deletion of "a" followed by a rename of "a" -> "b". Thus,
splitting of the original rewrite into a delete/add pair is important
here.
This splitting is represented by a flag we can set at the current delta.
While the flag is already being set in case we want to break rewrites,
we do not do so in case where the `GIT_DIFF_FIND_RENAMES_FROM_REWRITES`
flag is set. This can trigger an assert when we try to match the source
and target deltas.
Fix the issue by setting the `GIT_DIFF_FLAG__TO_SPLIT` flag at the delta
when it is a rename target and `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` is
set.
|
|
|
80e77b87
|
2018-02-20T10:03:48
|
|
tests: add rename-rewrite scenarios to "renames" repository
Add two more scenarios to the "renames" repository. The first scenario
has a major rewrite of a file and a delete of another file, the second
scenario has a deletion of a file and rename of another file to the
deleted file. Both scenarios will be used in the following commit.
|
|
|
d91da1da
|
2018-02-20T09:54:58
|
|
tests: diff::rename: use defines for commit OIDs
While we frequently reuse commit OIDs throughout the file, we do not
have any constants to refer to these commits. Make this a bit easier to
read by giving the commit OIDs somewhat descriptive names of what kind
of commit they refer to.
|
|
|
cabe16df
|
2018-02-19T10:18:59
|
|
tests: index::filemodes: fix use of uninitialized memory
The new index entry structure was not being initialized to all-zeroes.
As that structure is used to add a new entry to the current index, and
the hashing algorithm of the index making use of the uninitialized flags
to calculate the state, we might miscompute the hash of the entry and
add it at the wrong position. Later lookups would then fail.
Initialize the structure with `memset` to fix the test breaking on some
platforms.
|
|
|
5f774dbf
|
2018-02-11T10:14:13
|
|
git_index_add_frombuffer: only accept files/links
Ensure that the buffer given to `git_index_add_frombuffer` represents a
regular blob, an executable blob, or a link. Explicitly reject commit
entries (submodules) - it makes little sense to allow users to add a
submodule from a string; there's no possible path to success.
|