|
e087c0de
|
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>
|
|
24597812
|
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>
|
|
7db25870
|
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>
|
|
967da2c7
|
2018-06-27T17:30:12
|
|
Merge pull request #4688 from mystor/sorted_revwalk_reset
Fix interaction between limited flag and sorting over resets
|
|
0d1d9e1e
|
2018-06-27T17:28:40
|
|
Merge pull request #4691 from pks-t/pks/http-parser-fallthrough
deps: fix implicit fallthrough warning in http-parser
|
|
12232a5e
|
2018-06-27T17:19:37
|
|
Merge pull request #4698 from nelhage/fix-leaks
Fix assorted leaks found via fuzzing
|
|
5dd34702
|
2018-06-26T09:56:43
|
|
Merge branch 'nelhage/smart-no-pack'
|
|
9286e413
|
2018-06-26T09:56:06
|
|
smart protocol: correct error message capitalization
|
|
3a547417
|
2018-06-25T15:38:29
|
|
git_pkt_free: Allow freeing NULL
|
|
e6cdd17c
|
2018-06-25T13:57:19
|
|
Merge pull request #4695 from nelhage/git_pkt-type-confusion
Fix type confusion in git_smart__connect
|
|
983f72c5
|
2018-06-25T13:52:25
|
|
Merge pull request #4696 from nelhage/git_pkt_ref-check-len
Verify ref_pkt's are long enough
|
|
d58afb17
|
2018-06-24T22:28:37
|
|
git_smart__connect: free symrefs on error
|
|
cf335928
|
2018-06-24T22:22:40
|
|
git_smart__update_heads: free the old symref_target
|
|
e31c450b
|
2018-06-24T23:46:36
|
|
Fix another missing git_pkt_free
|
|
bf4c2c57
|
2018-06-24T21:56:51
|
|
wait_while_ack: use git_pkt_free
git__free is insufficient if the packet is a git_pkt_ref or another
type that requires freeing referenced structures.
|
|
437ee5a7
|
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);
```
|
|
0098d746
|
2018-06-24T06:51:31
|
|
Fix type confusion in git_smart__connect
Nothing verifies that t->refs[0] is a GIT_PKT_REF. A remote can send
another packet type, ultimately resulting in a type confusion in
`git_smart__detect_caps`
|
|
3eec73ae
|
2018-06-24T20:54:41
|
|
PACK packets are illegal while downloading refs
|
|
4fd81c53
|
2018-06-18T19:43:53
|
|
Clear revwalk sorting when resetting
Currently we fail to clear the sorting flag for revwalks when resetting.
This caused a poor interaction with the limited flag during a recent
patch. This patch clears the revwalk sorting flag and causes it to no
longer persist over resets.
|
|
cacbf998
|
2018-06-22T13:41:17
|
|
deps: fix implicit fallthrough warning in http-parser
GCC 7 has introduced new warnings for implicit fallthrough in switch
statements. Whenever there is no branch in a case block, GCC will watch
out for some heuristics which indicate that the implicit fallthrough is
intended, like a "fallthrough" comment. The third-party http-parser code
manages to trick this heuristic in one case, even though there is a
"FALLTHROUGH" comment. Fortunately, GCC has also added a strictness
level to the -Wimplicit-fallthrough diagnostic, such that we can loosen
this heuristic and make it more lax.
Set -Wimplicit-fallthrough=1 in http-parser's CMake build instructions,
which is the strictest level that gets rid of the warning. This level
will treat any kind of comment as a "fallthrough" comment, which
silences the warning.
|
|
b121b7ac
|
2018-06-22T18:28:44
|
|
Merge pull request #4411 from pks-t/pks/config-parse-cleanups
Config parser cleanups
|
|
e1e90dcc
|
2018-01-09T14:52:34
|
|
config_file: avoid free'ing OOM buffers
Buffers which ran out of memory will never have any memory attached to
them. As such, it is not necessary to call `git_buf_free` if the buffer
is out of memory.
|
|
83b5f161
|
2017-11-12T14:09:24
|
|
config_parse: always sanitize out-parameters in `parse_variable`
The `parse_variable` function has two out parameters `var_name` and
`var_value`. Currently, those are not being sanitized to `NULL`. when.
any error happens inside of the `parse_variable` function. Fix that.
While at it, the coding style is improved to match our usual coding
practices more closely.
|
|
e51e29e8
|
2017-11-12T13:59:47
|
|
config_parse: have `git_config_parse` own entry value and name
The function `git_config_parse` uses several callbacks to pass data
along to the caller as it parses the file. One design shortcoming here
is that strings passed to those callbacks are expected to be freed by
them, which is really confusing.
Fix the issue by changing memory ownership here. Instead of expecting
the `on_variable` callbacks to free memory for `git_config_parse`, just
do it inside of `git_config_parse`. While this obviously requires a bit
more memory allocation churn due to having to copy both name and value
at some places, this shouldn't be too much of a burden.
|
|
e212011b
|
2018-06-18T12:33:34
|
|
Merge pull request #4685 from csware/no-git_buf_free
Fix last references to deprecated git_buf_free
|
|
cc9c9522
|
2018-06-18T12:10:17
|
|
Merge pull request #4606 from libgit2/cmn/revwalk-iteration
revwalk: avoid walking the entire history when output is unsorted
|
|
b5818dda
|
2018-06-18T13:05:08
|
|
Fix last references to deprecated git_buf_free
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
ff98fec0
|
2018-06-18T10:25:07
|
|
revwalk: formatting updates
|
|
96882f20
|
2018-06-18T10:13:11
|
|
Merge pull request #4586 from emilio/mailmap
Add mailmap support.
|
|
f98131be
|
2018-06-17T00:40:25
|
|
Require the length argument to git_mailmap_from_buffer and make mailmap_add_buffer internal
|
|
0ecf0e33
|
2018-06-16T09:35:10
|
|
Merge pull request #4683 from pks-t/pks/tree-unused-functions
tree: remove unused functions
|
|
f0a1d76a
|
2018-06-15T13:21:59
|
|
tree: remove unused function `git_tree__prefix_position`
|
|
31f6b529
|
2018-06-15T13:21:08
|
|
tree: remove unused function `git_tree_entry_icmp`
|
|
678fa45b
|
2018-06-15T11:34:04
|
|
Merge pull request #4678 from staticfloat/sf/mbedtls_linkage
Link `mbedTLS` libraries in when `SHA1_BACKEND` == "mbedTLS"
|
|
c103616f
|
2018-06-15T10:32:24
|
|
Merge pull request #4676 from libgit2/editorconfig
editorconfig: allow trailing whitespace in markdown
|
|
9faf36a6
|
2018-06-14T22:48:58
|
|
mailmap: git_buf_free => git_buf_dispose
|
|
d91d2968
|
2018-06-14T16:49:48
|
|
mailmap: Hide EEXISTS to simplify git_mailmap_add_entry callers
|
|
c1a85ae2
|
2018-06-04T11:36:44
|
|
mailmap: Free the mailmap vector
|
|
56303e1a
|
2018-05-07T11:59:00
|
|
mailmap: API and style cleanup
|
|
a140c138
|
2018-04-08T03:01:37
|
|
mailmap: Updates tests for new API and features
|
|
8ff0504d
|
2018-04-08T03:01:14
|
|
mailmap: Rewrite API to support accurate mailmap resolution
|
|
18ff9bab
|
2018-03-27T22:48:03
|
|
mailmap: API and style cleanup
|
|
57cfeab9
|
2018-03-26T15:05:37
|
|
mailmap: Switch mailmap parsing to use the git_parse module
|
|
aa3a24a4
|
2018-03-26T14:44:15
|
|
mailmap: Clean up the mailmap fixture's .gitted directory
|
|
5c6c8a9b
|
2018-03-18T01:26:30
|
|
mailmap: Fix some other minor style nits
|
|
4ff44be8
|
2018-03-17T18:24:15
|
|
mailmap: Fix more bugs which snuck in when I rebased
|
|
983b8c2d
|
2018-03-17T18:15:41
|
|
mailmap: Add a bunch of tests for the new mailmap functionality
|
|
e3dcaca5
|
2018-03-17T18:15:01
|
|
mailmap: Integrate mailmaps with blame and signatures
|
|
b05fbba3
|
2018-03-17T18:14:31
|
|
mailmap: Make everything a bit more style conforming
|
|
939d8d57
|
2018-03-17T18:14:03
|
|
mailmap: Support path fixtures in cl_git_repository_init()
|
|
b88cbf8c
|
2018-03-18T01:40:47
|
|
mailmap: Add some super-basic tests
|
|
7bafd175
|
2018-03-18T01:39:57
|
|
mailmap: Don't error out when there's junk at the end of the line
Also matches git.
|
|
59fbf9cf
|
2018-03-17T18:29:34
|
|
mailmap: Don't return a freed pointer, even if we return an error code
|
|
97bc8988
|
2018-03-17T17:40:24
|
|
mailmap: Do not error out when the mailmap contains an invalid line
This matches git.
|
|
44112db2
|
2018-03-17T17:34:42
|
|
mailmap: Be consistent about checking len vs. len > 0
Not that it matters much anyway but...
|
|
ae5ee182
|
2018-03-17T17:33:48
|
|
mailmap: git_vector_get already checks bounds
|
|
ae222136
|
2018-03-17T02:33:48
|
|
mailmap: Some more style cleanup
|
|
49620359
|
2018-03-17T02:29:41
|
|
mailmap: Clean up mailmap parser, and finish API
|
|
7a169390
|
2018-03-15T16:34:30
|
|
mailmap: WIP mailmap support
|
|
23c6e894
|
2018-06-12T12:40:53
|
|
Merge pull request #4681 from pks-t/pks/indentation-tab-width
docs: fix statement about tab width
|
|
291cf12e
|
2018-06-12T12:40:11
|
|
Merge pull request #4680 from pks-t/pks/diff-opts-enum
diff: fix enum value being out of allowed range
|
|
0bfe5f78
|
2018-06-12T10:42:53
|
|
docs: fix statement about tab width
The libgit2 project mostly follows the coding style of git and thus
the linux project. While those two projects use a recommended tab width
of eight spaces, we instruct users to set their editor's tab width to
four spaces. Fix this to say eight instead.
|
|
2d9d2464
|
2018-06-12T10:34:10
|
|
diff: fix enum value being out of allowed range
The C89 standard states in §6.7.2.2 "Enumeration specifiers":
> The expression that defines the value of an enumeration constant shall
> be an integer constant expression that has a value representable as an
> int.
On most platforms, this effectively limits the range to a 32 bit signed
integer. The enum `git_diff_option_t` though recently gained an entry
`GIT_DIFF_INDENT_HEURISTIC = (1u << 31)`, which breaks this limit.
Fix the issue by using a gap in `git_diff_option_t`'s enum values. While
this has the benefit of retaining our API, it may break applications
which do not get recompiled after upgrading libgit2. But as we are
bumping the soversion on each release anyway and thus force a recompile
of dependents, this is not a problem.
|
|
3be73011
|
2018-06-11T18:26:22
|
|
Merge pull request #4436 from pks-t/pks/packfile-stream-free
pack: rename `git_packfile_stream_free`
|
|
e6444dac
|
2018-06-11T18:25:44
|
|
Merge pull request #4677 from libgit2/ethomson/memleaks
Stop leaking the memory
|
|
96212813
|
2018-06-11T17:11:36
|
|
stash test: free the commit
|
|
82849b96
|
2018-06-10T17:23:50
|
|
Test using `SHA1_BACKEND=mbedTLS` as well
|
|
b89162af
|
2018-06-10T17:26:08
|
|
Link `mbedTLS` libraries in when `SHA1_BACKEND == "mbedTLS"`
|
|
90c6fb0f
|
2018-06-10T17:33:06
|
|
Fix typo in adding `hash_mbedtls.c` to `SRC_SHA1`
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
56ffdfc6
|
2018-02-08T11:14:30
|
|
buffer: deprecate `git_buf_free` in favor of `git_buf_dispose`
|
|
396e4960
|
2018-02-08T11:05:17
|
|
common.h: create `GIT_DEPRECATED` macro
|
|
c8ee5270
|
2017-12-08T09:05:58
|
|
pack: rename `git_packfile_stream_free`
The function `git_packfile_stream_free` frees all state of the packfile
stream without freeing the structure itself. This naming makes it hard
to spot whether it will try to free the pointer itself or not, causing
potential future errors. Due to this reason, we have decided to name a
function freeing state without freeing the actual struture a "dispose"
function.
Rename `git_packfile_stream_free` to `git_packfile_stream_dispose` as a
first example following this rule.
|
|
123f01f0
|
2018-06-10T12:21:43
|
|
stash test: free the reference
|
|
795a5b28
|
2018-06-09T18:36:21
|
|
Merge pull request #4668 from novalis/bad-stash
Fix stash save bug with fast path index check
|
|
f81923ef
|
2018-06-09T18:31:57
|
|
Merge branch 'pks/docs-improvements'
|
|
634154ec
|
2018-06-09T18:27:18
|
|
editorconfig: allow trailing whitespace in markdown
Markdown uses trailing whitespace to indicate context; eg, a blank line
with four spaces indicates that there is a hard break between the
(indented) lines surrounding that line. Ensure that editors do not
remove this blank.
|
|
8a2de353
|
2018-06-09T18:25:46
|
|
Merge branch 'compat/clibs'
|
|
5e53f216
|
2018-06-09T18:24:27
|
|
docs: update release steps to include clib manifest
We've introduced a manifest for the clib version system that includes a
version number; we should update it at release time to correspond with
the version number in the header.
|
|
5cd5f7bd
|
2018-04-22T12:03:40
|
|
Include clib's package reference.
This PR introduces a new top-level file, `package.json`, which enables this repository compatibility with [`clib`](https://github.com/clibs/clib), an open source C package manager. By doing this, users of `clib` can quickly include the `libgit2` library within their project.
|
|
44788c96
|
2018-06-09T18:00:23
|
|
Merge pull request #4662 from pks-t/pks/gitfile-api
path: unify `git_path_is_*` APIs
|
|
bc0f3227
|
2018-06-09T17:59:46
|
|
Merge pull request #4670 from pks-t/pks/ignore-leadingdir
Fix negative gitignore rules with leading directories
|
|
0ef3242e
|
2018-06-07T16:41:55
|
|
Merge pull request #4576 from pks-t/pks/memory-allocator
Custom memory allocators
|
|
0f6348f4
|
2018-05-18T13:27:26
|
|
CHANGELOG.md: update changelog to mention custom memory allocators
|
|
74b7ddbf
|
2018-03-16T10:14:50
|
|
settings: allow swapping out memory allocator
Tie in the newly created infrastructure for swapping out memory
allocators into our settings code. A user can now simply use the new
option "GIT_OPT_SET_ALLOCATOR" with `git_libgit2_opts`, passing in an
already initialized allocator structure as vararg.
|
|
9865cd16
|
2018-03-20T14:23:49
|
|
alloc: make memory allocators use function pointers
Currently, our memory allocators are being redirected to the correct
implementation at compile time by simply using macros. In order to make
them swappable at runtime, this commit reshuffles that by instead making
use of a global "git_allocator" structure, whose pointers are set up to
reference the allocator functions. Like this, it becomes easy to swap
out allocators by simply setting these function pointers.
In order to initialize a "git_allocator", our provided allocators
"stdalloc" and "crtdbg" both provide an init function. This is being
called to initialize a passed in allocator struct and set up its members
correctly.
No support is yet included to enable users of libgit2 to switch out the
memory allocator at a global level.
|
|
08b318c0
|
2018-03-14T10:43:00
|
|
stdalloc: extend allocators by file and line
Our desired architecture would make allocators completely pluggable,
such that users of libgit2 can swap out memory allocators at runtime.
While making e.g. debugging easier by not having to do a separate build,
this feature can also help maintainers of bindings for libgit2 by tying
the memory allocations into the other language's memory system.
In order to do so, though, we first need to make our two different
pre-existing allocators "stdalloc" and "crtdbg" have the same function
signatures, as the "crtdbg" allocators all have an additional file and
line argument. This is required to build correct stack traces for
debugging memory allocations. As that feature may also be interesting to
authors of other applications for debugging libgit2, we now simply add
these arguments to our standard allocators.
Obviously, this may come with a performance penalty. During some simple
benchmarks no real impact could be measured though in contrast to a
simple pluggable allocator. The following table summarizes the
benchmarks. There were three different builds with our current standard
allocator ("standard"), with pluggable authenticators accessed via
function pointers ("pluggable") and for pluggable authenticators with
file and line being added ("fileline"). Furthermore, there were three
scenarios for 100.000.000 allocations of 100B ("small alloc"),
100.000.000 allocations of 100KB ("medium alloc"), and 1.000.000
allocations of 100MB. All results are best of 10 runs.
|------------|-------------------|-------------------|-------------------|
| build/test | small alloc | medium alloc | big alloc |
|------------|-------------------|-------------------|-------------------|
| standard | 4539779566, +0.0% | 5912927186, +0.0% | 5166935308, +0.0% |
|------------|-------------------|-------------------|-------------------|
| pluggable | 4611074505, +1.5% | 5979185308, +1.1% | 5388776352, +4.2% |
|------------|-------------------|-------------------|-------------------|
| fileline | 4588338192, +1.1% | 6004951910, +1.5% | 4942528135, -4.4% |
|------------|-------------------|-------------------|-------------------|
As can be seen, there is a performance overhead for pluggable
allocators. Furthermore, it can also be seen that there is some big
variance between runs, especially in the "big alloc" scenario. This is
probably being caused by nondeterministic behaviour in the kernel for
dynamic allocations. Still, it can be observed that there should be no
real difference between the "pluggable" and "fileline" allocators.
|
|
d2e996fa
|
2018-03-14T10:36:14
|
|
util: extract allocators into its own "alloc.h" header
Our "util.h" header is a grabbag of various different functions, where
many don't have a clear group they belong to. Our set of allocator
functions though can be clearly singled out as a single group of
functions that always belongs together. Furthermore, we will need to
implement additional functions relating to our allocators subsystem when
moving to pluggable allocators. Thus, we should just move these
functions into their own "alloc" module.
|
|
c47f7155
|
2018-03-14T10:34:59
|
|
util: extract `stdalloc` allocator into its own module
Right now, the standard allocator is being declared as part of the
"util.h" header as a set of inline functions. As with the crtdbg
allocator functions, these inline functions make it hard to convert to
function pointers for our allocators.
Create a new "stdalloc" module containing our standard allocations
functions to split these out. Convert the existing allocators to macros
which make use of the stdalloc functions.
|
|
496b0df2
|
2018-03-14T10:28:50
|
|
win32: crtdbg: provide independent `free` function
Currently, the `git__free` function is being defined in a single place,
only, disregarding whether we use our standard allocators or the crtdbg
allocators. This makes it a bit harder to convert our code base to use
pluggable allocators, and furthermore makes the border between our two
allocators a bit more blurry.
Implement a separate `git__crtdbg__free` function for the crtdbg
allocator in order to completely separate both allocator
implementations.
|
|
aab8f87b
|
2018-03-14T10:27:13
|
|
win32: crtdbg: internalize implementation of allocators
The crtdbg allocators are currently being implemented as inline
functions as part of the "w32_crtdbg_stacktrace.h" header. As we are
moving towards pluggable allocators with the help of function pointers,
though, we cannot make use of inlining anymore. Instead, we can only
have a single implementation of these allocating functions.
Move all implementations of the crtdbg allocators into
"w32_crtdbg_stacktrace.c".
|
|
422cd59b
|
2018-06-07T12:49:55
|
|
Merge pull request #4655 from glaubitz/alignment
index: Fix alignment issues in write_disk_entry()
|
|
534b70af
|
2018-06-07T12:30:59
|
|
Merge pull request #4558 from tiennou/travis/war-on-leaks
travis: war on leaks
|
|
5a7d454b
|
2018-06-04T12:56:08
|
|
Fix stash save bug with fast path index check
If the index contains stat data for a modified file, and the file is
not racily dirty, and there exists an untracked working tree directory
alphabetically after that file, and there are no other changes to the
repo, then git_stash_save would fail. It would confuse the untracked
working tree directory for the modified file, because they have the
same sha: zero. The wt directory has a sha of zero because it's a
directory, and the file would have a zero sha because we wouldn't read
the file -- we would just know that it doesn't match the index. To
fix this confusion, we simply check mode as well as SHA.
|
|
20306d36
|
2018-06-06T14:31:28
|
|
Merge pull request #4665 from neithernut/fix-refdb-glob
refdb_fs: fix regression: failure when globbing for non-existant references
|
|
991bf691
|
2018-06-06T13:55:16
|
|
Merge pull request #4673 from pks-t/pks/submodule-dupes-simplify-test
tests: submodule: do not rely on config iteration order
|
|
61eaaadf
|
2018-04-20T23:11:30
|
|
travis: enable -Werror in the script instead of using the matrix
|
|
149790b9
|
2018-04-20T23:11:28
|
|
scripts: remove extraneous semicolons
|
|
4c969618
|
2018-04-20T23:11:27
|
|
scripts: use leaks on macOS
|
|
0fb8c1d0
|
2018-04-20T23:11:25
|
|
valgrind: bump num-callers to 50 for fuller stack traces
|