|
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.
|
|
|
988757fe
|
2019-12-03T17:47:31
|
|
path: rename function that detects end of filename
The function `only_spaces_and_dots` used to detect the end of the
filename on win32. Now we look at spaces and dots _before_ the end of
the string _or_ a `:` character, which would signify a win32 alternate
data stream.
Thus, rename the function `ntfs_end_of_filename` to indicate that it
detects the (virtual) end of a filename, that any further characters
would be elided to the given path.
|
|
|
3828d7af
|
2019-08-05T00:12:36
|
|
Release v0.27.9
|
|
|
bdfeb32f
|
2019-08-05T00:11:54
|
|
v0.27.9: update changelog for security release
|
|
12bcc7a9
|
2019-06-21T15:53:54
|
|
commit_list: fix possible buffer overflow in `commit_quick_parse`
The function `commit_quick_parse` provides a way to quickly parse
parts of a commit without storing or verifying most of its
metadata. The first thing it does is calculating the number of
parents by skipping "parent " lines until it finds the first
non-parent line. Afterwards, this parent count is passed to
`alloc_parents`, which will allocate an array to store all the
parent.
To calculate the amount of storage required for the parents
array, `alloc_parents` simply multiplicates the number of parents
with the respective elements's size. This already screams "buffer
overflow", and in fact this problem is getting worse by the
result being cast to an `uint32_t`.
In fact, triggering this is possible: git-hash-object(1) will
happily write a commit with multiple millions of parents for you.
I've stopped at 67,108,864 parents as git-hash-object(1)
unfortunately soaks up the complete object without streaming
anything to disk and thus will cause an OOM situation at a later
point. The point here is: this commit was about 4.1GB of size but
compressed down to 24MB and thus easy to distribute.
The above doesn't yet trigger the buffer overflow, thus. As the
array's elements are all pointers which are 8 bytes on 64 bit, we
need a total of 536,870,912 parents to trigger the overflow to
`0`. The effect is that we're now underallocating the array
and do an out-of-bound writes. As the buffer is kindly provided
by the adversary, this may easily result in code execution.
Extrapolating from the test file with 67m commits to the one with
536m commits results in a factor of 8. Thus the uncompressed
contents would be about 32GB in size and the compressed ones
192MB. While still easily distributable via the network, only
servers will have that amount of RAM and not cause an
out-of-memory condition previous to triggering the overflow. This
at least makes this attack not an easy vector for client-side use
of libgit2.
|
|
|
7d3fd77d
|
2019-06-19T12:59:27
|
|
config: validate ownership of C:\ProgramData\Git\config before using it
When the VirtualStore feature is in effect, it is safe to let random
users write into C:\ProgramData because other users won't see those
files. This seemed to be the case when we introduced support for
C:\ProgramData\Git\config.
However, when that feature is not in effect (which seems to be the case
in newer Windows 10 versions), we'd rather not use those files unless
they come from a trusted source, such as an administrator.
This change imitates the strategy chosen by PowerShell's native OpenSSH
port to Windows regarding host key files: if a system file is owned
neither by an administrator, a system account, or the current user, it
is ignored.
|
|
|
2882803c
|
2019-01-28T10:43:37
|
|
CHANGELOG: there's changes (plural) not just one
|
|
|
8d1b36a6
|
2019-01-28T10:23:50
|
|
Merge pull request #4942 from libgit2/ethomson/v0.27.8
Release v0.27.8
|
|
|
703885a8
|
2019-01-18T22:23:52
|
|
version: bump to v0.27.8
|
|
|
e5081962
|
2019-01-18T22:22:47
|
|
CHANGELOG: update for v0.27.8
|
|
|
2236b3dd
|
2018-06-05T16:46:07
|
|
ignore: remove now-useless check for LEADINGDIR
When checking whether a rule negates another rule, we were checking
whether a rule had the `GIT_ATTR_FNMATCH_LEADINGDIR` flag set and, if
so, added a "/*" to its end before passing it to `fnmatch`. Our code now
sets `GIT_ATTR_FNMATCH_NOLEADINGDIR`, thus the `LEADINGDIR` flag shall
never be set. Furthermore, due to the `NOLEADINGDIR` flag, trailing
globs do not get consumed by our ignore parser anymore.
Clean up code by just dropping this now useless logic.
|
|
|
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.
|
|
|
ba724069
|
2018-11-14T12:33:38
|
|
patch_parse: remove unused function `parse_number`
The function `parse_number` was replaced by `git_parse_advance_digit`
which is provided by the parser interface in commit 252f2eeee (parse:
implement and use `git_parse_advance_digit`, 2017-07-14). As there are
no remaining callers, remove it.
|
|
|
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
|
|
|
2ffdb5b9
|
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.
|
|
|
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.
|
|
|
d64b0a69
|
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.
|
|
|
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.
|
|
ac5879de
|
2018-12-06T10:48:20
|
|
Typesetting conventions
|
|
|
a6ffb1ce
|
2018-12-04T10:59:25
|
|
Removed one null check
|
|
|
82209544
|
2018-12-04T10:12:24
|
|
Fix segfault in loose_backend__readstream
If the routine exits with error before stream or hash_ctx is initialized, the
program will segfault when trying to free them.
|
|
c3b2053d
|
2018-12-04T21:48:12
|
|
make proxy_stream_close close target stream even on errors
When git_filter_apply_fn callback returns a error while smudging proxy_stream_close
ends up returning without closing the stream. This is turn makes blob_content_to_file
crash as it asserts the stream being closed whether there are errors or not.
Closing the target stream on error fixes this problem.
|
|
8ce7272d
|
2018-12-14T14:43:09
|
|
annotated_commit: peel to commit instead of assuming we have one
We want to allow the creation of annotated commits out of annotated tags and for
that we have to peel the reference all the way to the commit instead of stopping
at the first id it provides.
|
|
|
0573e78d
|
2018-12-14T14:41:17
|
|
refs: constify git_reference_peel
We have no need to take a non-const reference. This does involve some other work
to make sure we don't mix const and non-const variables, but by splitting what
we want each variable to do we can also simplify the logic for when we do want
to free a new reference we might have allocated.
|
|
|
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
```
|
|
|
7529124b
|
2018-11-21T10:54:29
|
|
commit: fix out-of-bound reads when parsing truncated author fields
While commit objects usually should have only one author field, our commit
parser actually handles the case where a commit has multiple author fields
because some tools that exist in the wild actually write them. Detection of
those additional author fields is done by using a simple `git__prefixcmp`,
checking whether the current line starts with the string "author ". In case
where we are handed a non-NUL-terminated string that ends directly after the
space, though, we may have an out-of-bounds read of one byte when trying to
compare the expected final NUL byte.
Fix the issue by using `git__prefixncmp` instead of `git_prefixcmp`.
Unfortunately, a test cannot be easily written to catch this case. While we
could test the last error message and verify that it didn't in fact fail parsing
a signature (because that would indicate that it has in fact tried to parse the
additional "author " field, which it shouldn't be able to detect in the first
place), this doesn't work as the next line needs to be the "committer" field,
which would error out with the same error message even if we hadn't done an
out-of-bounds read.
As objects read from the object database are always NUL terminated, this issue
cannot be triggered in normal code and thus it's not security critical.
|
|
42c4c624
|
2018-08-17T18:51:56
|
|
config: assert that our parameters are valid
CID 1395011
|
|
|
a09a1028
|
2018-10-24T01:30:12
|
|
refs: assert that we're passed valid refs when renaming
CID 1382962
|
|
|
c7469503
|
2018-10-24T01:26:48
|
|
diff: assert that we're passed a valid git_diff object
CID 1386176, 1386177, 1388219
|
|
|
a4b332e8
|
2018-10-24T01:21:21
|
|
submodule: grab the error while loading from config
Previously, an error in `git_config_next` would be mistaken as a
successful load, because the previous call would have succeeded.
Coverity saw the subsequent check for a completed iteration as dead, so
let's make it useful again.
CID 1391374
|
|
|
313440c3
|
2018-12-19T13:37:26
|
|
Merge pull request #4916 from libgit2/ethomson/backport_0278
smart transport: only clear url on hard reset
|
|
|
8bc913a2
|
2018-11-07T15:31:21
|
|
smart transport: only clear url on hard reset
After creating a transport for a server, we expect to be able to call
`connect`, then invoke subsequent `action` calls. We provide the URL to
these `action` calls, although our built-in transports happen to ignore
it since they've already parsed it into an internal format that they
intend to use (`gitno_connection_data`).
In ca2eb4608243162a13c427e74526b6422d5a6659, we began clearing the URL
field after a connection, meaning that subsequent calls to transport
`action` callbacks would get a NULL URL, which went undetected since the
builtin transports ignore the URL when they're already connected
(instead of re-parsing it into an internal format).
Downstream custom transport implementations (eg, LibGit2Sharp) did
notice this change, however.
Since `reset_stream` is called even when we're not closing the
subtransport, update to only clear the URL when we're closing the
subtransport. This ensures that `action` calls will get the correct URL
information even after a connection.
|
|
|
f23dc5b2
|
2018-10-26T15:27:21
|
|
Merge pull request #4846 from pks-t/pks/v0.27.6
Bugix release v0.27.7
|
|
|
a0c286b5
|
2018-10-19T14:14:51
|
|
version: bump to v0.27.7
|
|
|
45d55562
|
2018-10-19T14:14:33
|
|
CHANGELOG: update for v0.27.7
|
|
|
80890b9a
|
2018-07-20T08:20:48
|
|
winhttp: retry erroneously failing requests
Early Windows TLS 1.2 implementations have an issue during key exchange
with OpenSSL implementations that cause negotiation to fail with the
error "the buffer supplied to a function was too small."
This is a transient error on the connection, so when that error is
received, retry up to 5 times to create a connection to the remote
server before actually giving up.
(cherry picked from commit dc371e3c5903760cc2334a0acfac9bce04479773)
|
|
ebdca44a
|
2018-09-02T11:38:43
|
|
git_remote_prune to be O(n * logn)
(cherry picked from commit bfec6526e931d7f6ac5ecc38c37e76163092bfda)
|
|
|
a77b64a5
|
2018-10-06T12:58:06
|
|
ignore unsupported http authentication schemes
auth_context_match returns 0 instead of -1 for unknown schemes to
not fail in situations where some authentication schemes are supported
and others are not.
apply_credentials is adjusted to handle auth_context_match returning
0 without producing authentication context.
(cherry picked from commit 475db39bb4c44a2221f340c66c227f555e478d10)
|
|
|
4ca4c7d1
|
2018-08-21T02:11:32
|
|
transport/http: do not return success if we failed to get a scheme
Otherwise we return a NULL context, which will get dereferenced in
apply_credentials.
(cherry picked from commit 1c949ce1483ca22a29e8f523360999cbbe411a50)
|
|
|
e78f9f66
|
2018-10-05T10:31:53
|
|
cmake: explicitly enable int-conversion warnings
While GCC enables int-conversion warnings by default, it will currently
only warn about such errors even in case where "-DENABLE_WERROR=ON" has
been passed to CMake. Explicitly enable int-conversion warnings by using
our `ENABLE_WARNINGS` macro, which will automatically use
"-Werror=int-conversions" in case it has been requested by the user.
(cherry picked from commit aa0ae59a2a31dc0ee5cc987066903d135a5f9e79)
|
|
|
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)
|
|
|
2e7d53ac
|
2018-09-17T20:38:05
|
|
cmake: enable -Wformat and -Wformat-security
We do not currently have any warnings in this regard, but it's good practice to
have them on in case we introduce something.
(cherry picked from commit f2c1153d4fa09a36be7c6b87e4f55325f6e5031e)
|
|
|
c0e038a2
|
2018-08-21T01:12:11
|
|
revwalk: The left operand of '<' is a garbage value
At line 594, we do this :
if (error < 0)
return error;
but if nothing was pushed in a GIT_SORT_TIME revwalk, we'd return
uninitialized stack data.
(cherry picked from commit aa8cb5866f1eabd92c8c08f7a8610d42df07375f)
|
|
|
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)
|
|
a5a0347d
|
2018-08-16T22:45:43
|
|
Fix leak in index.c
(cherry picked from commit 581d5492f6afdaf31a10e51187466a80ffc9f76f)
|
|
|
0fefd899
|
2018-08-17T15:56:30
|
|
util: make the qsort_r check work on macOS
This performs a compile-check by using CMake support, to differentiate the GNU
version from the BSD version of qsort_r.
Module taken from 4f252abea5f1d17c60f6ff115c9c44cc0b6f1df6, which I've checked
against CMake 2.8.11.
(cherry picked from commit 1a9cc18260b68b149476adb6f39e37ab47d3d21f)
|
|
|
fad59658
|
2018-08-09T12:48:26
|
|
diff: fix OOM on AIX when finding similar deltas in empty diff
The function `git_diff_find_similar` keeps a function of cache
similarity metrics signatures, whose size depends on the number of
deltas passed in via the `diff` parameter. In case where the diff is
empty and thus doesn't have any deltas at all, we may end up allocating
this cache via a call to `git__calloc(0, sizeof(void *))`. At least on
AIX, allocating 0 bytes will result in a `NULL` pointer being returned,
which causes us to erroneously return an OOM error.
Fix this situation by simply returning early in case where we are being
passed an empty diff, as we cannot find any similarities in that case
anyway.
(cherry picked from commit c65568d8c8c1bf4920393190e862819cd263f439)
|
|
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)
|
|
|
831a709d
|
2018-08-05T14:37:08
|
|
Add a comment
(cherry picked from commit ec76a1aa43321db2451e747d7a4408e780991c4a)
|
|
|
ab3f6099
|
2018-08-05T14:25:22
|
|
Don't error on missing section, just continue
(cherry picked from commit 019409be004fb73071415750e98db03d33fada47)
|
|
|
9023f8f6
|
2018-07-22T23:31:19
|
|
config_file: Don't crash on options without a section
(cherry picked from commit c4d7fa951acd066fd80d83954dd6082c1c7e9e1e)
|
|
e1295400
|
2018-08-04T19:30:40
|
|
parse: Do not initialize the content in context to NULL
String operations in libgit2 are supposed to never receive `NULL`, e.g.
they are not `NULL`-save. In the case of `git__linenlen()`, invocation
with `NULL` leads to undefined behavior.
In a `git_parse_ctx` however, the `content` field used in these
operations was initialized to `NULL` if the `git_parse_ctx_init()` was
called with `NULL` for `content` or `0` for `content_len`. For the
latter case, the initialization function even contained some logic for
initializing `content` with `NULL`.
This commit mitigates triggering undefined behavior by rewriting the
logic. Now `content` is always initialized to a non-null buffer. Instead
of a null buffer, an empty string is used for denoting an empty buffer.
(cherry picked from commit d1bfe614aa20a0bdaf76c6d418176320ab11baf4)
|
|
|
b8844566
|
2018-07-27T12:00:37
|
|
tree: rename from_tree to validate and clarify the tree in the test
(cherry picked from commit f00db9ed67423b04976f8d20b0de2ee1fb7c3993)
|
|
|
e91d6b5e
|
2018-09-27T11:18:00
|
|
fix check if blob is uninteresting when inserting tree to packbuilder
Blobs that have been marked as uninteresting should not be inserted into packbuilder
when inserting a tree. The check as to whether a blob was uninteresting looked at
the status for the tree itself instead of the blob.
This could cause significantly larger packfiles.
(cherry picked from commit b36cc7a4013a47856dade4226edc657906b82431)
|
|
|
b69089fd
|
2018-09-17T14:49:46
|
|
revwalk: only check the first commit in the list for an earlier timestamp
This is not a big deal, but it does make us match git more closely by checking
only the first. The lists are sorted already, so there should be no functional
difference other than removing a possible check from every iteration in the
loop.
(cherry picked from commit 12a1790d8e71087056d2b2de936ddae439e1d94c)
|
|
|
3cabf8d1
|
2018-09-17T14:39:58
|
|
revwalk: use the max value for a signed integer
When porting, we overlooked that the difference between git's and our's time
representation and copied their way of getting the max value.
Unfortunately git was using unsigned integers, so `~0ll` does correspond to
their max value, whereas for us it corresponds to `-1`. This means that we
always consider the last date to be smaller than the current commit's and always
think commits are interesting.
Change the initial value to the macro that gives us the maximum value on each
platform so we can accurately consider commits interesting or not.
(cherry picked from commit 46f35127b6fcfab87cb80d1b772ac7c662eafd38)
|
|
|
b133ab9b
|
2018-09-26T21:17:39
|
|
vector: do not realloc 0-size vectors
(cherry picked from commit e0afd1c21c4421cec4f67162021f835e2bbb7df6)
|
|
|
ebb0e37e
|
2018-09-26T19:15:35
|
|
vector: do not malloc 0-length vectors on dup
(cherry picked from commit fa48d2ea7d2d5dc9620e5c9f05ba8d788775582b)
|
|
|
5fc7d59c
|
2018-09-11T15:53:35
|
|
index: release the snapshot instead of freeing the index
Previously we would assert in index_free because the reader incrementation
would not be balanced. Release the snapshot normally, so the variable gets
decremented before the index is freed.
(cherry picked from commit c70713d6e4af563696563e410864eb4a6507757d)
|
|
|
54e7cf7e
|
2018-08-24T09:53:39
|
|
cmake: detect and use libc-provided iconv
While most systems provide a separate iconv library against which
applications can link, musl based systems do not provide such a library.
Instead, iconv functions are directly included in the C library. As our
current CMake module to locate the iconv library only checks whether a
library exists somewhere in the typical library directories, we will
never build libgit2 with libiconv support on such systems.
Extend the iconv module to also search whether libc provides iconv
functions, which we do by checking whether the `iconv_open` function
exists inside of libc. If this is the case, we will default to use the
libc provided one instead of trying to use a separate libiconv. While
this changes which iconv we use on systems where both libc and an
external libiconv exist, to the best of my knowledge common systems only
provide either one or the other.
Note that libiconv support in musl is held kind of basic. To quote musl
libc's page on functional differences from glibc [1]:
The iconv implementation musl is very small and oriented towards
being unobtrusive to static link. Its character set/encoding
coverage is very strong for its size, but not comprehensive like
glibc’s.
As we assume iconv to be a lot more capable than what musl provides,
some of our tests will fail if using iconv on musl-based platforms.
[1]: https://wiki.musl-libc.org/functional-differences-from-glibc.html
(cherry picked from commit 2e2d8c6493ec4d151c55d7421c93126267ee8e6d)
|
|
|
01b8bbf4
|
2018-08-21T01:55:56
|
|
remote: set the error before cleanup
Otherwise we'll return stack data to the caller.
(cherry picked from commit 22d013b657c5957fde31641351cb72d08cc192ae)
|
|
|
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
|
|
|
a7fbb051
|
2018-04-18T22:40:46
|
|
repository: being a worktree means we're not really bare
We were previously conflating any error into GIT_ENOTFOUND, which might
or might not be correct. This fixes the code so a config error is
bubbled up, as well as preserving the semantics in the face of
worktree-repositories
|
|
|
68e55c3a
|
2018-10-26T14:54:54
|
|
Merge pull request #4866 from pks-t/pks/v0.27.6-security
Release v0.27.6
|
|
|
b6998178
|
2018-10-19T14:10:27
|
|
version: bump to v0.27.6
|
|
|
c12975bf
|
2018-10-19T14:10:11
|
|
CHANGELOG: update changelog for v0.27.6
|
|
|
4f0e5f70
|
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.
(cherry picked from commit 7655b2d89e8275853d9921dd903dcdad9b3d4a7b)
|
|
|
6e40bb3a
|
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.
(cherry picked from commit ee11d47e3d907b66eeff99e0ba1e1c71e05164b7)
|
|
|
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)
|
|
|
0f7663a1
|
2018-10-18T14:37:55
|
|
util: avoid signed integer overflows in `git__strntol64`
While `git__strntol64` tries to detect integer overflows when doing the
necessary arithmetics to come up with the final result, it does the
detection only after the fact. This check thus relies on undefined
behavior of signed integer overflows. Fix this by instead checking
up-front whether the multiplications or additions will overflow.
Note that a detected overflow will not cause us to abort parsing the
current sequence of digits. In the case of an overflow, previous
behavior was to still set up the end pointer correctly to point to the
first character immediately after the currently parsed number. We do not
want to change this now as code may rely on the end pointer being set up
correctly even if the parsed number is too big to be represented as
64 bit integer.
(cherry picked from commit b09c1c7b636c4112e247adc24245c65f3f9478d0)
|
|
|
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)
|
|
|
2052a3cd
|
2018-10-18T11:58:14
|
|
global: replace remaining use of `git__strtol32`
Replace remaining uses of the `git__strtol32` function. While these uses
are all safe as the strings were either sanitized or from a trusted
source, we want to remove `git__strtol32` altogether to avoid future
misuse.
(cherry picked from commit 2613fbb26a3e1a34dda8a5d198c108626cfd6cc3)
|
|
|
61165dd4
|
2018-10-18T11:43:30
|
|
tree-cache: avoid out-of-bound reads when parsing trees
We use the `git__strtol32` function to parse the child and entry count
of treecaches from the index, which do not accept a buffer length. As
the buffer that is being passed in is untrusted data and may thus be
malformed and may not contain a terminating `NUL` byte, we can overrun
the buffer and thus perform an out-of-bounds read.
Fix the issue by uzing `git__strntol32` instead.
(cherry picked from commit 21652ee9de439e042cc2e69b208aa2ef8ce31147)
|
|
|
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)
|
|
|
334e6c69
|
2018-10-18T11:35:08
|
|
config: remove last instance of `git__strntol64`
When parsing integers from configuration values, we use `git__strtol64`.
This is fine to do, as we always sanitize values and can thus be sure
that they'll have a terminating `NUL` byte. But as this is the last
call-site of `git__strtol64`, let's just pass in the length explicitly
by calling `strlen` on the value to be able to remove `git__strtol64`
altogether.
(cherry picked from commit 1a2efd10bde66f798375e2f47ba57ef00ad5c193)
|
|
|
5ce26b18
|
2018-10-18T11:32:48
|
|
signature: avoid out-of-bounds reads when parsing signature dates
We use `git__strtol64` and `git__strtol32` to parse the trailing commit
or author date and timezone of signatures. As signatures are usually
part of a commit or tag object and thus essentially untrusted data, the
buffer may be misformatted and may not be `NUL` terminated. This may
lead to an out-of-bounds read.
Fix the issue by using `git__strntol64` and `git__strntol32` instead.
(cherry picked from commit 3db9aa6f79711103a331a2bbbd044a3c37d4f136)
|
|
|
76e57b4e
|
2018-10-18T11:29:06
|
|
index: avoid out-of-bounds read when reading reuc entry stage
We use `git__strtol64` to parse file modes of the index entries, which
does not limit the parsed buffer length. As the index can be essentially
treated as "untrusted" in that the data stems from the file system, it
may be misformatted and may not contain terminating `NUL` bytes. This
may lead to out-of-bounds reads when trying to parse index entries with
such malformatted modes.
Fix the issue by using `git__strntol64` instead.
(cherry picked from commit 600ceadd1426b874ae0618651210a690a68b27e9)
|
|
|
4dddcafb
|
2018-10-18T11:25:59
|
|
commit_list: avoid use of strtol64 without length limit
When quick-parsing a commit, we use `git__strtol64` to parse the
commit's time. The buffer that's passed to `commit_quick_parse` is the
raw data of an ODB object, though, whose data may not be properly
formatted and also does not have to be `NUL` terminated. This may lead
to out-of-bound reads.
Use `git__strntol64` to avoid this problem.
(cherry picked from commit 1a3fa1f5fafd433bdcf1834426d6963eff532125)
|
|
|
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)
|
|
|
1c02b896
|
2018-07-20T21:50:58
|
|
smart subtransport: free url when resetting stream
Free the url field when resetting the stream to avoid leaking it.
(cherry picked from commit ca2eb4608243162a13c427e74526b6422d5a6659)
|