|
21a2318b
|
2018-10-03T16:17:21
|
|
smart_pkt: do not accept callers passing in no line length
Right now, we simply ignore the `linelen` parameter of
`git_pkt_parse_line` in case the caller passed in zero. But in fact, we
never want to assume anything about the provided buffer length and
always want the caller to pass in the available number of bytes.
And in fact, checking all the callers, one can see that the funciton is
never being called in case where the buffer length is zero, and thus we
are safe to remove this check.
(cherry picked from commit 1bc5b05c614c7b10de021fa392943e8e6bd12c77)
|
|
|
5836d8b6
|
2018-08-09T11:16:15
|
|
smart_pkt: return parsed length via out-parameter
The `parse_len` function currently directly returns the parsed length of
a packet line or an error code in case there was an error. Instead,
convert this to our usual style of using the return value as error code
only and returning the actual value via an out-parameter. Thus, we can
now convert the output parameter to an unsigned type, as the size of a
packet cannot ever be negative.
While at it, we also move the check whether the input buffer is long
enough into `parse_len` itself. We don't really want to pass around
potentially non-NUL-terminated buffers to functions without also passing
along the length, as this is dangerous in the unlikely case where other
callers for that function get added. Note that we need to make sure
though to not mess with `GIT_EBUFS` error codes, as these indicate not
an error to the caller but that he needs to fetch more data.
(cherry picked from commit c05790a8a8dd4351e61fc06c0a06c6a6fb6134dc)
|
|
|
a8356af8
|
2018-08-09T11:04:42
|
|
smart_pkt: fix buffer overflow when parsing "unpack" packets
When checking whether an "unpack" packet returned the "ok" status or
not, we use a call to `git__prefixcmp`. In case where the passed line
isn't properly NUL terminated, though, this may overrun the line buffer.
Fix this by using `git__prefixncmp` instead.
(cherry picked from commit 5fabaca801e1f5e7a1054be612e8fabec7cd6a7f)
|
|
|
3fd6ce0d
|
2018-08-09T10:57:06
|
|
smart_pkt: adjust style of "ref" packet parsing function
While the function parsing ref packets doesn't have any immediately
obvious buffer overflows, it's style is different to all the other
parsing functions. Instead of checking buffer length while we go, it
does a check up-front. This causes the code to seem a lot more magical
than it really is due to some magic constants. Refactor the function to
instead make use of the style of other packet parser and verify buffer
lengths as we go.
(cherry picked from commit 5edcf5d190f3b379740b223ff6a649d08fa49581)
|
|
|
e14dab2f
|
2018-08-09T10:46:58
|
|
smart_pkt: check whether error packets are prefixed with "ERR "
In the `git_pkt_parse_line` function, we determine what kind of packet
a given packet line contains by simply checking for the prefix of that
line. Except for "ERR" packets, we always only check for the immediate
identifier without the trailing space (e.g. we check for an "ACK"
prefix, not for "ACK "). But for "ERR" packets, we do in fact include
the trailing space in our check. This is not really much of a problem at
all, but it is inconsistent with all the other packet types and thus
causes confusion when the `err_pkt` function just immediately skips the
space without checking whether it overflows the line buffer.
Adjust the check in `git_pkt_parse_line` to not include the trailing
space and instead move it into `err_pkt` for consistency.
(cherry picked from commit 786426ea6ec2a76ffe2515dc5182705fb3d44603)
|
|
|
02e4b27f
|
2018-08-09T11:03:37
|
|
smart_pkt: fix "ng" parser accepting non-space character
When parsing "ng" packets, we blindly assume that the character
immediately following the "ng" prefix is a space and skip it. As the
calling function doesn't make sure that this is the case, we can thus
end up blindly accepting an invalid packet line.
Fix the issue by using `git__prefixncmp`, checking whether the line
starts with "ng ".
(cherry picked from commit b5ba7af2d30c958b090dcf135749d9afe89ec703)
|
|
|
cfb9802b
|
2018-08-09T10:46:26
|
|
smart_pkt: explicitly avoid integer overflows when parsing packets
When parsing data, progress or error packets, we need to copy the
contents of the rest of the current packet line into the flex-array of
the parsed packet. To keep track of this array's length, we then assign
the remaining length of the packet line to the structure. We do have a
mismatch of types here, as the structure's `len` field is a signed
integer, while the length that we are assigning has type `size_t`.
On nearly all platforms, this shouldn't pose any problems at all. The
line length can at most be 16^4, as the line's length is being encoded
by exactly four hex digits. But on a platforms with 16 bit integers,
this assignment could cause an overflow. While such platforms will
probably only exist in the embedded ecosystem, we still want to avoid
this potential overflow. Thus, we now simply change the structure's
`len` member to be of type `size_t` to avoid any integer promotion.
(cherry picked from commit 40fd84cca68db24f325e460a40dabe805e7a5d35)
|
|
|
a7e87dd5
|
2018-08-09T10:36:44
|
|
smart_pkt: honor line length when determining packet type
When we parse the packet type of an incoming packet line, we do not
verify that we don't overflow the provided line buffer. Fix this by
using `git__prefixncmp` instead and passing in `len`. As we have
previously already verified that `len <= linelen`, we thus won't ever
overflow the provided buffer length.
(cherry picked from commit 4a5804c983317100eed509537edc32d69c8d7aa2)
|
|
|
3bbda7d7
|
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)
|
|
|
8cd0a897
|
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)
|
|
|
5d108c9a
|
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)
|
|
|
82c3fc33
|
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)
|
|
e91024e1
|
2018-06-28T05:27:36
|
|
Small style tweak, and set an error
(cherry picked from commit 895a668e19dc596e7b12ea27724ceb7b68556106)
|
|
|
c83c59b8
|
2018-06-26T02:32:50
|
|
Remove GIT_PKT_PACK entirely
(cherry picked from commit 90cf86070046fcffd5306915b57786da054d8964)
|
|
8ced4627
|
2018-08-11T13:06:14
|
|
Fix 'invalid packet line' for ng packets containing errors
(cherry picked from commit 50dd7fea5ad1bf6c013b72ad0aa803a9c84cdede)
|
|
ffc20564
|
2018-09-05T11:49:13
|
|
Prevent heap-buffer-overflow
When running repack while doing repo writes, `packfile_load__cb()` can see some temporary files in the directory that are bigger than the usual, and makes `memcmp` overflow on the `p->pack_name` string. ASAN detected this. This just uses `strncmp`, that should not have any performance impact and is safe for comparing strings of different sizes.
```
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61200001a3f3 at pc 0x7f4a9e1976ec bp 0x7ffc1f80e100 sp 0x7ffc1f80d8b0
READ of size 89 at 0x61200001a3f3 thread T0
SCARINESS: 26 (multi-byte-read-heap-buffer-overflow)
#0 0x7f4a9e1976eb in __interceptor_memcmp.part.78 (/build/cfgr-admin#link-tree/libtools_build_sanitizers_asan-ubsan-py.so+0xcf6eb)
#1 0x7f4a518c5431 in packfile_load__cb /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb_pack.c:213
#2 0x7f4a518d9582 in git_path_direach /build/libgit2/0.27.0/src/libgit2-0.27.0/src/path.c:1134
#3 0x7f4a518c58ad in pack_backend__refresh /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb_pack.c:347
#4 0x7f4a518c1b12 in git_odb_refresh /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:1511
#5 0x7f4a518bff5f in git_odb__freshen /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:752
#6 0x7f4a518c17d4 in git_odb_stream_finalize_write /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:1415
#7 0x7f4a51b9d015 in Repository_write /build/pygit2/0.27.0/src/pygit2-0.27.0/src/repository.c:509
```
(cherry picked from commit d22cd1f4a4c10ff47b04c57560e6765d77e5a8fd)
|
|
|
c4db1715
|
2018-09-03T10:49:46
|
|
config_parse: refactor error handling when parsing multiline variables
The current error handling for the multiline variable parser is a bit
fragile, as each error condition has its own code to clear memory.
Instead, unify error handling as far as possible to avoid this
repetitive code. While at it, make use of `GITERR_CHECK_ALLOC` to
correctly handle OOM situations and verify that the buffer we print into
does not run out of memory either.
(cherry picked from commit bc63e1ef521ab5900dc0b0dcd578b8bf18627fb1)
|
|
|
c18c913c
|
2018-09-01T03:50:26
|
|
config: Fix a leak parsing multi-line config entries
(cherry picked from commit 38b852558eb518f96c313cdcd9ce5a7af6ded194)
|
|
|
da70156e
|
2018-08-25T17:04:39
|
|
config: convert unbounded recursion into a loop
(cherry picked from commit a03113e80332fba6c77f43b21d398caad50b4b89)
|
|
a8db6c92
|
2017-11-30T15:40:13
|
|
util: introduce `git__prefixncmp` and consolidate implementations
Introduce `git_prefixncmp` that will search up to the first `n`
characters of a string to see if it is prefixed by another string.
This is useful for examining if a non-null terminated character
array is prefixed by a particular substring.
Consolidate the various implementations of `git__prefixcmp` around a
single core implementation and add some test cases to validate its
behavior.
(cherry picked from commit 86219f40689c85ec4418575223f4376beffa45af)
|
|
|
5f557780
|
2018-06-24T19:47:08
|
|
Verify ref_pkt's are long enough
If the remote sends a too-short packet, we'll allow `len` to go
negative and eventually issue a malloc for <= 0 bytes on
```
pkt->head.name = git__malloc(alloclen);
```
(cherry picked from commit 437ee5a70711ac2e027877d71ee4ae17e5ec3d6c)
|
|
9561ec83
|
2017-08-22T16:29:07
|
|
smart: typedef git_pkt_type and clarify recv_pkt return type
(cherry picked from commit 08961c9d0d6927bfcc725bd64c9a87dbcca0c52c)
|
|
|
e98d0a37
|
2018-08-06T10:49:54
|
|
Merge pull request #4757 from pks-t/pks/v0.26.6
Release v0.26.6
|
|
|
81532654
|
2018-08-03T11:24:31
|
|
version: bump to v0.26.6
|
|
|
495bc486
|
2018-08-03T11:24:14
|
|
CHANGELOG.md: document security release v0.26.6
|
|
|
50705a2a
|
2018-07-19T13:00:42
|
|
smart_pkt: fix potential OOB-read when processing ng packet
OSS-fuzz has reported a potential out-of-bounds read when processing a
"ng" smart packet:
==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6310000249c0 at pc 0x000000493a92 bp 0x7ffddc882cd0 sp 0x7ffddc882480
READ of size 65529 at 0x6310000249c0 thread T0
SCARINESS: 26 (multi-byte-read-heap-buffer-overflow)
#0 0x493a91 in __interceptor_strchr.part.35 /src/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:673
#1 0x813960 in ng_pkt libgit2/src/transports/smart_pkt.c:320:14
#2 0x810f79 in git_pkt_parse_line libgit2/src/transports/smart_pkt.c:478:9
#3 0x82c3c9 in git_smart__store_refs libgit2/src/transports/smart_protocol.c:47:12
#4 0x6373a2 in git_smart__connect libgit2/src/transports/smart.c:251:15
#5 0x57688f in git_remote_connect libgit2/src/remote.c:708:15
#6 0x52e59b in LLVMFuzzerTestOneInput /src/download_refs_fuzzer.cc:145:9
#7 0x52ef3f in ExecuteFilesOnyByOne(int, char**) /src/libfuzzer/afl/afl_driver.cpp:301:5
#8 0x52f4ee in main /src/libfuzzer/afl/afl_driver.cpp:339:12
#9 0x7f6c910db82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
#10 0x41d518 in _start
When parsing an "ng" packet, we keep track of both the current position
as well as the remaining length of the packet itself. But instead of
taking care not to exceed the length, we pass the current pointer's
position to `strchr`, which will search for a certain character until
hitting NUL. It is thus possible to create a crafted packet which
doesn't contain a NUL byte to trigger an out-of-bounds read.
Fix the issue by instead using `memchr`, passing the remaining length as
restriction. Furthermore, verify that we actually have enough bytes left
to produce a match at all.
OSS-Fuzz-Issue: 9406
|
|
|
7e12ca68
|
2018-08-06T08:57:20
|
|
travis: force usage of Xcode 8.3 image
Travis has upgraded the default Xcode images from 8.3 to 9.4 on 31st
July 2018, including an upgrade to macOS 10.13. Unfortunately, this
breaks our CI builds on our maintenance branches. As we do not want to
include mayor changes to fix the integration right now, we force use of
the old Xcode 8.3 images.
|
|
|
a3e53c16
|
2018-07-09T14:11:45
|
|
Merge pull request #4718 from pks-t/pks/v0.26.5
Release v0.26.5
|
|
|
440a3636
|
2018-07-05T14:33:53
|
|
version: bump to v0.26.5
|
|
|
188fef5e
|
2018-07-05T14:20:57
|
|
CHANGELOG: add release notes for v0.26.5
|
|
|
47ea1f58
|
2018-07-05T13:30:46
|
|
delta: fix overflow when computing limit
When checking whether a delta base offset and length fit into the base
we have in memory already, we can trigger an overflow which breaks the
check. This would subsequently result in us reading memory from out of
bounds of the base.
The issue is easily fixed by checking for overflow when adding `off` and
`len`, thus guaranteeting that we are never indexing beyond `base_len`.
This corresponds to the git patch 8960844a7 (check patch_delta bounds
more carefully, 2006-04-07), which adds these overflow checks.
Reported-by: Riccardo Schirone <rschiron@redhat.com>
|
|
|
25d4a8c9
|
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>
|
|
|
8ab4f363
|
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>
|
|
|
ca55adaa
|
2018-06-04T12:18:40
|
|
Merge pull request #4666 from pks-t/pks/v0.26.4
Release v0.26.4
|
|
|
9fcd4772
|
2018-05-29T14:05:33
|
|
version: bump library version to 0.26.4
|
|
|
ef5265e2
|
2018-05-29T14:05:10
|
|
CHANGELOG: update for v0.26.4
|
|
ea55c77c
|
2018-05-24T21:58:40
|
|
path: hand-code the zero-width joiner as UTF-8
|
|
|
95a0ab89
|
2018-05-24T20:28:36
|
|
submodule: plug leaks from the escape detection
|
|
|
d1aaa5e2
|
2018-05-24T19:05:59
|
|
submodule: replace index with strchr which exists on Windows
|
|
|
f78b6907
|
2018-05-24T19:00:13
|
|
submodule: the repostiory for _name_is_valid should not be const
We might modify caches due to us trying to load the configuration to figure out
what kinds of filesystem protections we should have.
|
|
|
98e8b11c
|
2018-05-23T08:40:17
|
|
path: check for a symlinked .gitmodules in fs-agnostic code
We still compare case-insensitively to protect more thoroughly as we don't know
what specifics we'll see on the system and it's the behaviour from git.
|
|
|
1c1e32b7
|
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.
|
|
|
5b855194
|
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.
|
|
|
17df18ae
|
2018-05-22T15:48:38
|
|
index: stat before creating the entry
This is so we have it available for the path validity checking. In a later
commit we will start rejecting `.gitmodules` files as symlinks.
|
|
|
644c973f
|
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.
|
|
|
2143a0de
|
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.
|
|
|
3adb0dc3
|
2018-05-22T13:58:24
|
|
path: expose dotgit detection functions per filesystem
These will be used by the checkout code to detect them for the particular
filesystem they're on.
|
|
dc5591b4
|
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.
|
|
|
f98d140b
|
2018-05-16T15:56:04
|
|
path: add functions to detect .gitconfig and .gitattributes
|
|
|
4656e9c4
|
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.
|
|
|
9893f56b
|
2018-05-16T14:47:04
|
|
path: provide a generic function for checking dogit files on NTFS
It checks against the 8.3 shortname variants, including the one which includes
the checksum as part of its name.
|
|
|
f43ade0e
|
2018-05-16T11:56:04
|
|
path: provide a generic dogit checking function for HFS
This lets us check for other kinds of reserved files.
|
|
|
4a1753c2
|
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.
|
|
|
f77e40a1
|
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.
|
|
|
2fc15ae8
|
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.
|
|
|
8af6bce2
|
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.
|
|
|
999200cc
|
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.
|
|
|
b55bb43d
|
2018-03-12T13:50:02
|
|
Merge pull request #4475 from pks-t/pks/v0.26.1-backports
v0.26.3 backports
|
|
|
bb00842f
|
2018-03-10T17:57:40
|
|
Bump version to v0.26.3
|
|
|
7c8ddef0
|
2018-03-10T17:57:18
|
|
CHANGELOG.md: update for v0.26.3
|
|
|
9ab8d153
|
2018-02-25T15:46:51
|
|
winhttp: enable TLS 1.2 on Windows 7 and earlier
Versions of Windows prior to Windows 8 do not enable TLS 1.2 by default,
though support may exist. Try to enable TLS 1.2 support explicitly on
connections.
This request may fail if the operating system does not have TLS 1.2
support - the initial release of Vista lacks TLS 1.2 support (though
it is available as a software update) and XP completely lacks TLS 1.2
support. If this request does fail, the HTTP context is still valid,
and still maintains the original protocol support. So we ignore the
failure from this operation.
|
|
|
aa0127c0
|
2018-02-27T11:24:30
|
|
winhttp: include constants for TLS 1.1/1.2 support
For platforms that do not define `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1`
and/or `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2`.
|
|
|
9bdc00b1
|
2018-02-27T10:32:29
|
|
mingw: update TLS option flags
Include the constants for `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1` and
`WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2` so that they can be used by mingw.
This updates both the `deps/winhttp` framework (for classic mingw) and
adds the defines for mingw64, which does not use that framework.
|
|
|
1b853c48
|
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.
|
|
|
73615900
|
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.
|
|
|
3983fc1d
|
2018-02-18T16:10:33
|
|
checkout: take mode into account when comparing index to baseline
When checking out a file, we determine whether the baseline (what we
expect to be in the working directory) actually matches the contents
of the working directory. This is safe behavior to prevent us from
overwriting changes in the working directory.
We look at the index to optimize this test: if we know that the index
matches the working directory, then we can simply look at the index
data compared to the baseline.
We have historically compared the baseline to the index entry by oid.
However, we must also compare the mode of the two items to ensure that
they are identical. Otherwise, we will refuse to update the working
directory for a mode change.
|
|
|
e74e05ed
|
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.
|
|
|
e229e90d
|
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.
|
|
|
be205dfa
|
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.
|
|
b3c0d43c
|
2018-01-22T14:44:31
|
|
merge: virtual commit should be last argument to merge-base
Our virtual commit must be the last argument to merge-base: since our
algorithm pushes _both_ parents of the virtual commit, it needs to be
the last argument, since merge-base:
> Given three commits A, B and C, git merge-base A B C will compute the
> merge base between A and a hypothetical commit M
We want to calculate the merge base between the actual commit ("two")
and the virtual commit ("one") - since one actually pushes its parents
to the merge-base calculation, we need to calculate the merge base of
"two" and the parents of one.
|
|
|
3619e0f0
|
2018-01-22T23:56:22
|
|
Add failing test case for virtual commit merge base issue
|
|
|
dc51d774
|
2018-01-21T16:50:40
|
|
merge::trees::recursive: test for virtual base building
Virtual base building: ensure that the virtual base is created and
revwalked in the same way as git.
|
|
|
b2b37077
|
2018-01-21T18:05:45
|
|
merge: reverse merge bases for recursive merge
When the commits being merged have multiple merge bases, reverse the
order when creating the virtual merge base. This is for compatibility
with git's merge-recursive algorithm, and ensures that we build
identical trees.
Git does this to try to use older merge bases first. Per 8918b0c:
> It seems to be the only sane way to do it: when a two-head merge is
> done, and the merge-base and one of the two branches agree, the
> merge assumes that the other branch has something new.
>
> If we start creating virtual commits from newer merge-bases, and go
> back to older merge-bases, and then merge with newer commits again,
> chances are that a patch is lost, _because_ the merge-base and the
> head agree on it. Unlikely, yes, but it happened to me.
|
|
|
457a81bb
|
2018-01-21T18:01:20
|
|
oidarray: introduce git_oidarray__reverse
Provide a simple function to reverse an oidarray.
|
|
|
08ab5902
|
2018-01-21T16:41:49
|
|
Introduce additional criss-cross merge branches
|
|
5e97bdaf
|
2018-01-22T11:55:28
|
|
odb: export mempack backend
Fixes #4492, #4496.
|
|
e83efde4
|
2017-12-23T14:59:07
|
|
Fix unpack double free
If an element has been cached, but then the call to
packfile_unpack_compressed() fails, the very next thing that happens is
that its data is freed and then the element is not removed from the
cache, which frees the data again.
This change sets obj->data to NULL to avoid the double-free. It also
stops trying to resolve deltas after two continuous failed rounds of
resolution, and adds a test for this.
|
|
|
a521f5b1
|
2017-12-15T10:47:01
|
|
diff_file: properly refcount blobs when initializing file contents
When initializing a `git_diff_file_content` from a source whose data is
derived from a blob, we simply assign the blob's pointer to the
resulting struct without incrementing its refcount. Thus, the structure
can only be used as long as the blob is kept alive by the caller.
Fix the issue by using `git_blob_dup` instead of a direct assignment.
This function will increment the refcount of the blob without allocating
new memory, so it does exactly what we want. As
`git_diff_file_content__unload` already frees the blob when
`GIT_DIFF_FLAG__FREE_BLOB` is set, we don't need to add new code
handling the free but only have to set that flag correctly.
|
|
|
34f1ded9
|
2017-12-13T00:19:41
|
|
stransport: provide error message on trust failures
Fixes #4440
|
|
|
7cc80546
|
2018-01-03T12:54:42
|
|
streams: openssl: fix thread-safety for OpenSSL error messages
The function `ERR_error_string` can be invoked without providing a
buffer, in which case OpenSSL will simply return a string printed into a
static buffer. Obviously and as documented in ERR_error_string(3), this
is not thread-safe at all. As libgit2 is a library, though, it is easily
possible that other threads may be using OpenSSL at the same time, which
might lead to clobbered error strings.
Fix the issue by instead using a stack-allocated buffer. According to
the documentation, the caller has to provide a buffer of at least 256
bytes of size. While we do so, make sure that the buffer will never get
overflown by switching to `ERR_error_string_n` to specify the buffer's
size.
|
|
|
7ad0cee6
|
2017-12-08T10:10:19
|
|
hash: openssl: check return values of SHA1_* functions
The OpenSSL functions `SHA1_Init`, `SHA1_Update` and `SHA1_Final` all
return 1 for success and 0 otherwise, but we never check their return
values. Do so.
|
|
|
8f189cbf
|
2017-12-15T15:01:50
|
|
Simplified overflow condition
|
|
|
feb00daf
|
2017-12-09T05:26:27
|
|
Using unsigned instead
|
|
|
a42e11ae
|
2017-12-08T06:00:27
|
|
libFuzzer: Prevent a potential shift overflow
The type of |base_offset| in get_delta_base() is `git_off_t`, which is a
signed `long`. That means that we need to make sure that the 8 most
significant bits are zero (instead of 7) to avoid an overflow when it is
shifted by 7 bits.
Found using libFuzzer.
|
|
|
a3cd5e94
|
2017-12-06T03:03:18
|
|
libFuzzer: Fix missing trailer crash
This change fixes an invalid memory access when the trailer is missing /
corrupt.
Found using libFuzzer.
|
|
|
5cc3971a
|
2017-12-06T03:22:58
|
|
libFuzzer: Fix a git_packfile_stream leak
This change ensures that the git_packfile_stream object in
git_indexer_append() does not leak when the stream has errors.
Found using libFuzzer.
|
|
|
049e1de5
|
2017-11-30T18:10:28
|
|
openssl: fix thread-safety on non-glibc POSIX systems
While the OpenSSL library provides all means to work safely in a
multi-threaded application, we fail to do so correctly. Quoting from
crypto_lock(3):
OpenSSL can safely be used in multi-threaded applications provided
that at least two callback functions are set, locking_function and
threadid_func.
We do in fact provide the means to set up the locking function via
`git_openssl_set_locking()`, where we initialize a set of locks by using
the POSIX threads API and set the correct callback function to lock and
unlock them.
But what we do not do is setting the `threadid_func` callback. This
function is being used to correctly locate thread-local data of the
OpenSSL library and should thus return per-thread identifiers. Digging
deeper into OpenSSL's documentation, the library does provide a fallback
in case that locking function is not provided by the user. On Windows
and BeOS we should be safe, as it simply "uses the system's default
thread identifying API". On other platforms though OpenSSL will fall
back to using the address of `errno`, assuming it is thread-local.
While this assumption holds true for glibc-based systems, POSIX in fact
does not specify whether it is thread-local or not. Quoting from
errno(3p):
It is unspecified whether errno is a macro or an identifier declared
with external linkage.
And in fact, with musl there is at least one libc implementation which
simply declares `errno` as a simple `int` without being thread-local. On
those systems, the fallback threadid function of OpenSSL will not be
thread-safe.
Fix this by setting up our own callback for this setting. As users of
libgit2 may want to set it themselves, we obviously cannot always set
that function on initialization. But as we already set up primitives for
threading in `git_openssl_set_locking()`, this function becomes the
obvious choice where to implement the additional setup.
|
|
|
3c4e0cee
|
2017-11-30T15:12:48
|
|
diff_generate: fix unsetting diff flags
The macro `DIFF_FLAG_SET` can be used to set or unset a flag by
modifying the diff's bitmask. While the case of setting the flag is
handled correctly, the case of unsetting the flag was not. Instead of
inverting the flags, we are inverting the value which is used to decide
whether we want to set or unset the bits.
The value being used here is a simple `bool` which is `false`. As that
is being uplifted to `int` when getting the bitwise-complement, we will
end up retaining all bits inside of the bitmask. As that's only ever
used to set `GIT_DIFF_IGNORE_CASE`, we were actually always ignoring
case for generated diffs.
Fix that by instead getting the bitwise-complement of `FLAG`, not `VAL`.
|
|
|
05a753d4
|
2017-11-30T15:09:05
|
|
diff: remove unused macros `DIFF_FLAG_*`
In commit 9be638ecf (git_diff_generated: abstract generated diffs,
2016-04-19), the code for generated diffs was moved out of the generic
"diff.c" and instead into its own module. During that conversion, it was
forgotten to remove the macros `DIFF_FLAG_IS_SET`, `DIFF_FLAG_ISNT_SET`
and `DIFF_FLAG_SET`, which are now only used in "diff_generated.c".
Remove those macros now.
|
|
5c3a42ad
|
2017-11-25T15:48:03
|
|
Include git2/worktree.h in git2.h
I'm not sure if worktree.h was intentionally left out of git2.h. Looks like an oversight since it is in fact documented.
|
|
68842cbb
|
2017-10-29T12:28:43
|
|
Ignore trailing whitespace in .gitignore files (as git itself does)
|
|
e66bc08c
|
2016-06-15T01:59:56
|
|
checkout: test force checkout when mode changes
Test that we can successfully force checkout a target when the file
contents are identical, but the mode has changed.
|
|
|
8631357e
|
2017-10-07T12:23:33
|
|
checkout: do not test file mode on Windows
On Windows, we do not support file mode changes, so do not test
for type changes between the disk and tree being checked out.
We could have false positives since the on-disk file can only have
an (effective) mode of 0100644 since NTFS does not support executable
files. If the tree being checked out did have an executable file,
we would erroneously decide that the file on disk had been changed.
|
|
|
24388179
|
2016-06-15T02:00:35
|
|
checkout: treat files as modified if mode differs
When performing a forced checkout, treat files as modified when the
workdir or the index is identical except for the mode. This ensures
that force checkout will update the mode to the target. (Apply this
check for regular files only, if one of the items was a file and the
other was another type of item then this would be a typechange and
handled independently.)
|
|
|
f41e86d6
|
2017-10-06T12:05:26
|
|
transports: smart: fix memory leak when skipping symbolic refs
When we setup the revision walk for negotiating references with a
remote, we iterate over all references, ignoring tags and symbolic
references. While skipping over symbolic references, we forget to free
the looked up reference, resulting in a memory leak when the next
iteration simply overwrites the variable.
Fix that issue by freeing the reference at the beginning of each
iteration and collapsing return paths for error and success.
|
|
|
cda18f9b
|
2017-10-06T11:24:11
|
|
refs: do not use peeled OID if peeling to a tag
If a reference stored in a packed-refs file does not directly point to a
commit, tree or blob, the packed-refs file will also will include a
fully-peeled OID pointing to the first underlying object of that type.
If we try to peel a reference to an object, we will use that peeled OID
to speed up resolving the object.
As a reference for an annotated tag does not directly point to a commit,
tree or blob but instead to the tag object, the packed-refs file will
have an accomodating fully-peeled OID pointing to the object referenced
by that tag. When we use the fully-peeled OID pointing to the referenced
object when peeling, we obviously cannot peel that to the tag anymore.
Fix this issue by not using the fully-peeled OID whenever we want to
peel to a tag. Note that this does not include the case where we want to
resolve to _any_ object type. Existing code may make use from the fact
that we resolve those to commit objects instead of tag objects, even
though that behaviour is inconsistent between packed and loose
references. Furthermore, some tests of ours make the assumption that we
in fact resolve those references to a commit.
|
|
c2702235
|
2017-01-20T23:14:19
|
|
Use SOCK_CLOEXEC when creating sockets
|
|
|
93ecb61a
|
2017-10-07T11:25:12
|
|
proxy: rename the options freeing function
|
|
|
27a8092b
|
2017-09-27T15:30:19
|
|
curl: free the user-provided proxy credentials
|
|
|
8d7dcb10
|
2017-09-27T15:27:32
|
|
curl: free the proxy options
|