|
a9b5270b
|
2019-10-07T21:18:19
|
|
examples: checkout: implement guess heuristic for remote branches
|
|
f04a58b0
|
2019-10-03T12:55:48
|
|
Merge pull request #4445 from tiennou/shallow/dry-commit-parsing
DRY commit parsing
|
|
5cf17e0f
|
2019-10-03T09:39:42
|
|
commit_list: store in/out-degrees as uint16_t
The commit list's in- and out-degrees are currently stored as `unsigned
short`. When assigning it the value of `git_array_size`, which returns
an `size_t`, this generates a warning on some Win32 platforms due to
loosing precision.
We could just cast the returned value of `git_array_size`, which would
work fine for 99.99% of all cases as commits typically have less than
2^16 parents. For crafted commits though we might end up with a wrong
value, and thus we should definitely check whether the array size
actually fits into the field.
To ease the check, let's convert the fields to store the degrees as
`uint16_t`. We shouldn't rely on such unspecific types anyway, as it may
lead to different behaviour across platforms. Furthermore, this commit
introduces a new `git__is_uint16` function to check whether it actually
fits -- if not, we return an error.
|
|
5988cf34
|
2017-12-15T18:11:51
|
|
commit_list: unify commit information parsing
|
|
1c847a6a
|
2018-10-25T19:40:19
|
|
commit: generic parse mechanism
This allows us to pick which data from a commit we're interested in.
This will be used by the revwalk code, which is only interested in
parents' and committer data.
|
|
0ec0b2bb
|
2019-09-28T17:39:09
|
|
Merge pull request #5239 from pks-t/pks/docker-non-root-builds
azure: avoid building and testing in Docker as root
|
|
63307cba
|
2019-09-28T17:32:18
|
|
Merge pull request #5226 from pks-t/pks/regexp-api
regexp: implement a new regular expression API
|
|
70325370
|
2019-09-27T11:16:02
|
|
Merge pull request #5106 from tiennou/fix/ref-api-fixes
git_refdb API fixes
|
|
257dd59d
|
2019-09-26T10:52:03
|
|
Merge pull request #5242 from csware/no-enum-for-flags
Don't use enum for flags
|
|
452b7f8f
|
2019-09-25T20:29:21
|
|
Don't use enum for flags
Using an `enum` causes trouble when used with C++ as bitwise operations are not possible w/o casting (e.g., `opts.flags &= ~GIT_BLOB_FILTER_CHECK_FOR_BINARY;` is invalid as there is no `&=` operator for `enum`).
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
3c884cc3
|
2019-09-21T15:05:36
|
|
azure: avoid building and testing in Docker as root
Right now, all tests in libgit2's CI are being executed as root
user. As libgit2 will usually not run as a root user in "normal"
usecases and furthermore as there are tests that rely on the
ability to _not_ be able to create certain paths, let's instead
create an unprivileged user "libgit2" and use that across all
docker images.
|
|
9cd5240e
|
2019-09-21T19:13:40
|
|
Merge pull request #5240 from pks-t/pks/valgrind-suppress-gcrypt
valgrind: suppress memory leaks in libssh2_session_handshake
|
|
56d5b443
|
2019-09-21T17:55:54
|
|
valgrind: suppress memory leaks in libssh2_session_handshake
On Ubuntu, the combination of libgcrypt and libssh2 is quite old and
known to contain memory leaks. We thus have several functions listed in
our suppressions file that are known to leak. Due to a recent update of
libssh2 or libgcrypt, there now are new memory leaks caused by
libssh2_session_handshake and libssh2_init that cause the CI to fail.
Add a new suppression to fix the issue.
|
|
3c1aa232
|
2019-09-21T16:09:00
|
|
Merge pull request #5232 from pks-t/pks/buffer-ensure-size-oom
buffer: fix writes into out-of-memory buffers
|
|
7aacf027
|
2019-09-13T08:55:33
|
|
global: convert all users of POSIX regex to use our new regexp API
The old POSIX regex API has been superseded by our new regexp API.
Convert all users to make use of the new one.
|
|
d77378eb
|
2019-09-13T08:54:26
|
|
regexp: implement new regular expression API
We currently support a set of different regular expression backends with
PCRE, PCRE2, regcomp(3P) and regcomp_l(3). The current implementation of
this is done via a simple POSIX wrapper that either directly uses
supplied functions or that is a very small wrapper.
To support PCRE and PCRE2, we use their provided <pcreposix.h> and
<pcre2posix.h> wrappers. These wrappers are implemented in such a way
that the accompanying libraries pcre-posix and pcre2-posix provide the
same symbols as the libc ones, namely regcomp(3P) et al. This works out
on some systems just fine, most importantly on glibc-based ones, where
the regular expression functions are implemented as weak aliases and
thus get overridden by linking in the pcre{,2}-posix library. On other
systems we depend on the linking order of libc and pcre library, and as
libc always comes first we will end up with the functions of the libc
implementation. As a result, we may use the structures `regex_t` and
`regmatch_t` declared by <pcre{,2}posix.h>, but use functions defined by
the libc, leading to segfaults.
The issue is not easily solvable. Somed distributions like Debian have
resolved this by patching PCRE and PCRE2 to carry custom prefixes to all
the POSIX function wrappers. But this is not supported by upstream and
thus inherently unportable between distributions. We could instead try
to modify linking order, but this starts becoming fragile and will not
work e.g. when libgit2 is loaded via dlopen(3P) or similar ways. In the
end, this means that we simply cannot use the POSIX wrappers provided by
the PCRE libraries at all.
Thus, this commit introduces a new regular expression API. The new API
is on a tad higher level than the previous POSIX abstraction layer, as
it tries to abstract away any non-portable flags like e.g. REG_EXTENDED,
which has no equivalents in all of our supported backends. As there are
no users of POSIX regular expressions that do _not_ reguest REG_EXTENDED
this is fine to be abstracted away, though. Due to the API being
higher-level than before, it should generally be a tad easier to use
than the previous one.
Note: ideally, the new API would've been called `git_regex_foobar` with
a file "regex.h" and "regex.c". Unfortunately, this is currently
impossible to implement due to naming clashes between the then-existing
"regex.h" and <regex.h> provided by the libc. As we add the source
directory of libgit2 to the header search path, an include of <regex.h>
would always find our own "regex.h". Thus, we have to take the bitter
pill of adding one more character to all the functions to disambiguate
the includes.
To improve guarantees around cross-backend compatibility, this commit
also brings along an improved regular expression test suite
core::regexp.
|
|
f585b129
|
2019-09-12T14:29:28
|
|
posix: remove superseded POSIX regex wrappers
The old POSIX regex wrappers have been superseded by our own regexp API
that provides a higher-level abstraction. Remove the POSIX wrappers in
favor of the new one.
|
|
174b7a32
|
2019-09-19T12:24:06
|
|
buffer: fix printing into out-of-memory buffer
Before printing into a `git_buf` structure, we always call `ENSURE_SIZE`
first. This macro will reallocate the buffer as-needed depending on
whether the current amount of allocated bytes is sufficient or not. If
`asize` is big enough, then it will just do nothing, otherwise it will
call out to `git_buf_try_grow`. But in fact, it is insufficient to only
check `asize`.
When we fail to allocate any more bytes e.g. via `git_buf_try_grow`,
then we set the buffer's pointer to `git_buf__oom`. Note that we touch
neither `asize` nor `size`. So if we just check `asize > targetsize`,
then we will happily let the caller of `ENSURE_SIZE` proceed with an
out-of-memory buffer. As a result, we will print all bytes into the
out-of-memory buffer instead, resulting in an out-of-bounds write.
Fix the issue by having `ENSURE_SIZE` verify that the buffer is not
marked as OOM. Add a test to verify that we're not writing into the OOM
buffer.
|
|
208f1d7a
|
2019-09-19T12:46:37
|
|
buffer: fix infinite loop when growing buffers
When growing buffers, we repeatedly multiply the currently allocated
number of bytes by 1.5 until it exceeds the requested number of bytes.
This has two major problems:
1. If the current number of bytes is tiny and one wishes to resize
to a comparatively huge number of bytes, then we may need to loop
thousands of times.
2. If resizing to a value close to `SIZE_MAX` (which would fail
anyway), then we probably hit an infinite loop as multiplying the
current amount of bytes will repeatedly result in integer
overflows.
When reallocating buffers, one typically chooses values close to 1.5 to
enable re-use of resulting memory holes in later reallocations. But
because of this, it really only makes sense to use a factor of 1.5
_once_, but not looping until we finally are able to fit it. Thus, we
can completely avoid the loop and just opt for the much simpler
algorithm of multiplying with 1.5 once and, if the result doesn't fit,
just use the target size. This avoids both problems of looping
extensively and hitting overflows.
This commit also adds a test that would've previously resulted in an
infinite loop.
|
|
3e8a17b0
|
2019-09-21T15:18:42
|
|
buffer: fix memory leak if unable to grow buffer
If growing a buffer fails, we set its pointer to the static
`git_buf__oom` structure. While we correctly free the old pointer if
`git__malloc` returned an error, we do not free it if there was an
integer overflow while calculating the new allocation size. Fix this
issue by freeing the pointer to plug the memory leak.
|
|
bfdb9793
|
2019-09-21T14:54:18
|
|
Merge pull request #5237 from tiennou/fix/gssapi-cred
cred: add missing private header in GSSAPI block
|
|
49a3289e
|
2019-09-21T08:25:23
|
|
cred: add missing private header in GSSAPI block
Should have been part of 8bf0f7eb26c65b2b937b1f40a384b9b269b0b76d
|
|
aa407ca3
|
2019-09-19T13:23:59
|
|
Merge pull request #5206 from tiennou/cmake/pkgconfig-building
CMake pkg-config modulification
|
|
1995fe8e
|
2019-09-19T13:16:03
|
|
Merge pull request #5229 from ddevault/irc
Update chat resources in README.md
|
|
68cfb580
|
2019-09-19T10:27:33
|
|
Merge pull request #5223 from tiennou/fix/transport-header-split
Circular header splitting
|
|
e24b8852
|
2019-09-15T17:01:35
|
|
Update chat resources in README.md
|
|
564b3ffc
|
2019-08-17T12:34:59
|
|
cmake: add missing requires to the .pc file
|
|
d80d9d56
|
2019-08-17T12:17:21
|
|
cmake: streamline *.pc file handling via a module
|
|
71ca3dc7
|
2019-09-12T16:50:30
|
|
transport: move transport-related typedef in transport.h
|
|
606f6e21
|
2019-09-09T17:01:44
|
|
cert: move cert enums & struct to its own header
|
|
8bf0f7eb
|
2019-09-09T13:00:27
|
|
cred: separate public interface from low-level details
|
|
c97cf08a
|
2019-09-13T11:20:54
|
|
Merge pull request #5198 from pks-t/pks/azure-docker-builds
azure: build Docker images as part of the pipeline
|
|
5d8a4659
|
2019-09-13T10:31:49
|
|
Merge pull request #5195 from tiennou/fix/commitish-smart-push
smart: use push_glob instead of manual filtering
|
|
212b6f65
|
2019-08-02T14:00:21
|
|
cmake: fix various misuses of MESSAGE()
The MESSAGE() function expects as first argument the message type, e.g.
STATUS or FATAL_ERROR. In some places, we were misusing this to either
not provide any type, which would then erroneously print the message to
standard error, or to use FATAL instead of FATAL_ERROR.
Fix all of these instances. Also, remove some MESSAGE invocations that
are obvious leftovers from debugging the build system.
|
|
e77fdf87
|
2019-08-02T13:49:36
|
|
cmake: properly abort if no mbedTLS cert location is found
When using mbedTLS as backend, then the user may specify the location of
where system certificates are installed. If no such location is provided
by the user, CMake will try to autodetect the location by using the
openssl executable, if installed. If no location could be detected, then
the mbedTLS is essentially worthless as it is completely unable to
verify any certificates.
To avoid use of such misconfigured mbedTLS configurations, let's error
out if we were unable to find out the location.
|
|
48d23a8c
|
2019-08-02T12:36:19
|
|
azure: convert to use Ninja as build tool
While we were still supporting Trusty, using Ninja as a build tool would
have required us to first setup pip and then use it to install Ninja.
As a result, the speedups from using Ninja were drowned out by the
time required to install Ninja. But as we have deprecated Trusty now,
both Xenial and Bionic have recent versions of Ninja in their
repositories and thus we can now use Ninja.
|
|
4e07a205
|
2019-08-02T13:29:54
|
|
docker: fix Valgrind errors on Xenial by updating to v3.12.0
The Valgrind version shipped with Xenial has some bugs that keep our
tests from working due to bad interactions with openssl [1]. Fix this by
using the "hola-launchpad/valgrind" PPA that provides a newer version
for which the bug has been fixed.
[1]: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1574437
|
|
3c59d451
|
2019-08-02T12:34:10
|
|
docker: use "--no-install-recommends" to reduce build time
Pass the flag "--no-install-recommends" to apt-get in order to trim down
the number of packages installed, both reducing build time and image
size. As this also causes some required packages to not be installed
anymore, add these explicitly to the set of packages installed.
|
|
39b7e8b0
|
2019-08-02T12:26:30
|
|
docker: convert apt-get to use best practices
Reformat both Xenial and Bionic's Dockerfiles to use best practices.
Most importantly, we now run `apt-get update` and `apt-get install` in
one step followed up by removing the package lists to speed up
installation and keep down the image size.
|
|
9f91d57e
|
2019-08-02T14:25:02
|
|
docker: install libssh2 1.8.2 on Xenial
While Xenial provides libssh2 in its repositories, it only has version
1.5.0 available. This version will unfortunately not be able to connect
to GitHub due to their removal of weak cryptographic standards [1]. To
still enable our CI to execute tests against GitHub, we thus have to
update the provided libssh2 version to a newer one.
Manually install libssh2 1.8.2 on Xenial. There's no need to do the same
for Bionic, as it already provides libssh2 1.8.0.
[1]: https://github.blog/2018-02-01-crypto-removal-notice/
|
|
253dbea2
|
2019-08-02T10:21:32
|
|
docker: install mbedTLS on both Bionic and Xenial
We're about to phase out support for Trusty, but neither Bionic nor
Xenial images provide the mbedTLS library that's available in Trusty.
Build them for both to pull them in line with Trusty.
|
|
bbc0b20b
|
2019-08-02T10:27:24
|
|
azure: fix Coverity's build due to wrong container name
The Coverity build is still referencing an old "trusty-openssl"
container that is not provided by either our own now-inlined images nor
by the libgit2/libgit2-docker repository.
Convert it to build and use Xenial images instead.
|
|
76327381
|
2019-08-02T10:50:11
|
|
azure: deprecate Trusty in favor of Xenial
Support for the LTS release Ubuntu 14.04 Trusty has been dropped in
April 2019, but Azure is still using Trusty as its primary platform to
build and test against. Let's deprecate it in favor of Xenial.
|
|
5a6740e7
|
2019-08-02T09:58:55
|
|
azure: build Docker images as part of the pipeline
The Docker images used for our continuous integration builds currently
live in the libgit2/libgit2-docker repository. To make any changes in
them, one has to make a PR there, get it reviewed, re-build the images
and publish them to Docker Hub. This process is slow and tedious, making
it harder than necessary to perform any updates to our Docker-based
build pipeline.
To fix this, we include all Dockerfiles used by Azure from the mentioned
repository and inline them into our own repo. Instead of having to
manually push them to the CI, it will now build the required containers
on each pull request, allowing much greater flexibility.
|
|
7475dfa0
|
2019-09-12T11:29:30
|
|
Merge pull request #5216 from stinb/ntlm-openssl-headers
ntlm: fix failure to find openssl headers
|
|
561a3a20
|
2019-09-12T10:01:11
|
|
Merge pull request #5222 from tiennou/cmake/spurious-backend-logging
cmake: remove extraneous logging
|
|
1725ce0a
|
2019-09-11T09:37:24
|
|
Merge pull request #5224 from lrm29/check_if_repository_memory_leak
open:fix memory leak when passing NULL to git_repository_open_ext
|
|
dde6d9c7
|
2019-09-10T17:09:57
|
|
open:move all cleanup code to cleanup label in git_repository_open_ext
|
|
b545be3d
|
2019-09-10T11:14:36
|
|
open:fix memory leak when passing NULL to git_repository_open_ext
|
|
1ed10009
|
2019-09-06T10:32:06
|
|
cmake: remove extraneous logging
|
|
c3a7892f
|
2019-09-09T13:10:24
|
|
Merge pull request #5209 from mkostyuk/apply-wrong-patch
apply: Fix a patch corruption related to EOFNL handling
|
|
17d6cd45
|
2019-09-09T13:06:22
|
|
Merge pull request #5210 from buddyspike/master
ignore: correct handling of nested rules overriding wild card unignore
|
|
4d3392dd
|
2019-09-09T13:03:42
|
|
Merge pull request #5214 from pks-t/pks/diff-iterator-allocation-fixes
Memory allocation fixes for diff generator
|
|
39028eb6
|
2019-09-09T13:00:53
|
|
Merge pull request #5212 from libgit2/ethomson/creds_for_scheme
Use an HTTP scheme that supports the given credentials
|
|
8c142241
|
2019-06-14T08:20:05
|
|
refdb: make sure to remove packed refs first
This fixes part of the issue where, given a concurrent `git pack-refs`,
a ref lookup could return an old, vestigial value from the packed file,
as the valid loose one would have been deleted.
|
|
171116e7
|
2019-06-14T06:50:41
|
|
refdb: repurpose filesystem prune function
|
|
8fd855fd
|
2019-02-02T19:00:51
|
|
refdb: reorder parameters for consistency
|
|
9b25cf15
|
2019-02-02T19:00:49
|
|
refdb: fix packed_delete clobbering some errors
In the case of a failed lookup, we'd paper over that by writing back
the packed-refs successfully.
|
|
0a88c83d
|
2019-02-02T19:00:47
|
|
refdb: make low-level deletion helpers explicit
|
|
baf411e7
|
2019-02-02T19:00:45
|
|
refdb: ensure all mandatory functions are provided at setup time
|
|
c2cf9844
|
2019-02-02T19:00:43
|
|
refdb: check the version of the backend we're about to set
|
|
8db9fd3b
|
2019-02-02T19:00:41
|
|
refdb: documentation
|
|
7218cf47
|
2019-08-29T15:03:46
|
|
ntlm: fix failure to find openssl headers
|
|
585fbd74
|
2019-08-28T23:18:31
|
|
apply: Test for EOFNL mishandling when several hunks are processed
Introduce an unit test to validate that git_apply__patch() properly
handles EOFNL changes in case of patches with several hunks.
|
|
a7b4b639
|
2019-08-24T12:14:31
|
|
ignore: correct handling of nested rules overriding wild card unignore
problem:
filesystem_iterator loads .gitignore files in top-down order.
subsequently, ignore module evaluates them in the order they are loaded.
this creates a problem if we have unignored a rule (using a wild card)
in a sub dir and ignored it again in a level further below (see the test
included in this patch).
solution:
process ignores in reverse order.
closes #4963
|
|
5fc27aac
|
2019-08-27T13:38:08
|
|
Merge pull request #5208 from mkostyuk/apply-removed-new-file
apply: git_apply_to_tree fails to apply patches that add new files
|
|
5498c318
|
2019-08-27T13:10:53
|
|
apply: free test data
|
|
6de48085
|
2019-08-27T11:29:24
|
|
Merge pull request #5189 from libgit2/ethomson/attrs_from_head
Optionally read `.gitattributes` from HEAD
|
|
aaa48d06
|
2019-08-27T11:26:50
|
|
Merge pull request #5196 from pks-t/pks/config-include-onbranch
config: implement "onbranch" conditional
|
|
699de9c5
|
2019-08-27T10:36:17
|
|
iterator: remove duplicate memset
When allocating new tree iterator frames, we zero out the allocated
memory twice. Remove one of the `memset` calls.
|
|
9ca7a60e
|
2019-08-27T10:36:20
|
|
iterator: avoid leaving partially initialized frame on stack
When allocating tree iterator entries, we use GIT_ERROR_ALLOC_CHECK` to
check whether the allocation has failed. The macro will cause the
function to immediately return, though, leaving behind a partially
initialized iterator frame.
Fix the issue by manually checking for memory allocation errors and
using `goto done` in case of an error, popping the iterator frame.
|
|
fe241071
|
2019-08-27T10:36:19
|
|
diff_generate: detect memory allocation errors when preparing opts
When preparing options for the two iterators that are about to be
diffed, we allocate a common prefix for both iterators depending on
the options passed by the user. We do not check whether the allocation
was successful, though. In fact, this isn't much of a problem, as using
a `NULL` prefix is perfectly fine. But in the end, we probably want to
detect that the system doesn't have any memory left, as we're unlikely
to be able to continue afterwards anyway.
While the issue is being fixed in the newly created function
`diff_prepare_iterator_opts`, it has been previously existing in the
previous macro `DIFF_FROM_ITERATORS` already.
|
|
8a23597b
|
2019-08-27T10:36:18
|
|
diff_generate: refactor `DIFF_FROM_ITERATORS` macro of doom
While the `DIFF_FROM_ITERATORS` does make it shorter to implement the
various `git_diff_foo_to_bar` functions, it is a complex and unreadable
beast that implicitly assumes certain local variable names. This is not
something desirable to have at all and obstructs understanding and more
importantly debugging the code by quite a bit.
The `DIFF_FROM_ITERATORS` macro basically removed the burden of having
to derive the options for both iterators from a pair of iterator flags
and the diff options. This patch introduces a new function that does the
that exact and refactors all callers to manage the iterators by
themselves.
As we potentially need to allocate a shared prefix for the
iterator, we need to tell the caller to allocate that prefix as soon as
the options aren't required anymore. Thus, the function has a `char
**prefix` out pointer that will get set to the allocated string and
subsequently be free'd by the caller.
While this patch increases the line count, I personally deem this to an
acceptable tradeoff for increased readbiblity.
|
|
4e20c7b1
|
2019-08-25T22:11:39
|
|
Merge pull request #5213 from boardwalk/dskorupski/fix_include_case
Fix include casing for case-sensitive filesystems.
|
|
44d5e47d
|
2019-08-24T10:39:56
|
|
Fix include casing for case-sensitive filesystems.
|
|
4de51f9e
|
2019-08-23T16:05:28
|
|
http: ensure the scheme supports the credentials
When a server responds with multiple scheme support - for example,
Negotiate and NTLM are commonly used together - we need to ensure that
we choose a scheme that supports the credentials.
|
|
60319788
|
2019-08-23T09:58:15
|
|
Merge pull request #5054 from tniessen/util-use-64-bit-timer
util: use 64 bit timer on Windows
|
|
feac5945
|
2019-08-23T09:42:35
|
|
Merge pull request #5200 from pks-t/pks/memory-allocation-audit
Memory allocation audit
|
|
53f51c60
|
2019-08-21T19:48:05
|
|
smart: implement by-date insertion when revwalking
|
|
4b91f058
|
2019-08-21T19:43:06
|
|
revwalk: expose more ways of scheduling commits
Before we can tweak the revwalk to be more efficent when negotiating,
we need to add an "insertion mode" option. Since there's already an implicit
set of those, make it visible, at least privately.
|
|
8cbef12d
|
2019-08-08T11:52:54
|
|
util: do not perform allocations in insertsort
Our hand-rolled fallback sorting function `git__insertsort_r` does an
in-place sort of the given array. As elements may not necessarily be
pointers, it needs a way of swapping two values of arbitrary size, which
is currently implemented by allocating a temporary buffer of the
element's size. This is problematic, though, as the emulated `qsort`
interface doesn't provide any return values and thus cannot signal an
error if allocation of that temporary buffer has failed.
Convert the function to swap via a temporary buffer allocated on the
stack. Like this, it can `memcpy` contents of both elements in small
batches without requiring a heap allocation. The buffer size has been
chosen such that in most cases, a single iteration of copying will
suffice. Most importantly, it can fully contain `git_oid` structures and
pointers.
Add a bunch of tests for the `git__qsort_r` interface to verify nothing
breaks. Furthermore, this removes the declaration of `git__insertsort_r`
and makes it static as it is not used anywhere else.
|
|
f3b3e543
|
2019-08-08T11:34:01
|
|
xdiff: catch memory allocation errors
The xdiff code contains multiple call sites where the results of
`xdl_malloc` are not being checked for memory allocation errors.
Add checks to fix possible segfaults due to `NULL` pointer accesses.
|
|
c2dd895a
|
2019-08-08T10:47:29
|
|
transports: http: check for memory allocation failures
When allocating a chunk that is used to write to HTTP streams, we do not
check for memory allocation errors. This may lead us to write to a
`NULL` pointer and thus cause a segfault.
Fix this by adding a call to `GIT_ERROR_CHECK_ALLOC`.
|
|
08699541
|
2019-08-08T10:46:42
|
|
trailer: check for memory allocation errors
The "trailer.c" code has been copied mostly verbatim from git.git with
minor adjustments, only. As git.git's `xmalloc` function, which aborts
on memory allocation errors, has been swapped out for `git_malloc`,
which doesn't abort, we may inadvertently access `NULL` pointers.
Add checks to fix this.
|
|
8c7d9761
|
2019-08-08T10:45:12
|
|
posix: fix direct use of `malloc`
In "posix.c" there are multiple callsites which execute `malloc` instead
of `git__malloc`. Thus, users of library are not able to track these
allocations with a custom allocator.
Convert these call sites to use `git__malloc` instead.
|
|
a477bff1
|
2019-08-08T10:44:57
|
|
indexer: catch OOM when adding expected OIDs
When adding OIDs to the indexer's map of yet-to-be-seen OIDs to verify
that packfiles are complete, we do so by first allocating a new OID and
then calling `git_oidmap_set` on it. There was no check for memory
allocation errors in place, though, leading to possible segfaults due to
trying to copy data to a `NULL` pointer.
Verify the result of `git__malloc` with `GIT_ERROR_CHECK_ALLOC` to fix
the issue.
|
|
d4fe402b
|
2019-08-08T10:36:33
|
|
merge: check return value of `git_commit_list_insert`
The function `git_commit_list_insert` dynamically allocates memory and
may thus fail to insert a given commit, but we didn't check for that in
several places in "merge.c".
Convert surrounding functions to return error codes and check whether
`git_commit_list_insert` was successful, returning an error if not.
|
|
c0486188
|
2019-08-08T10:28:09
|
|
blame_git: detect memory allocation errors
The code in "blame_git.c" was mostly imported from git.git with only
minor changes. One of these changes was to use our own allocators
instead of git's `xmalloc`, but there's a subtle difference: `xmalloc`
would abort the program if unable to allocate any memory, bit
`git__malloc` doesn't. As we didn't check for memory allocation errors
in some places, we might inadvertently dereference a `NULL` pointer in
out-of-memory situations.
Convert multiple functions to return proper error codes and add calls to
`GIT_ERROR_CHECK_ALLOC` to fix this.
|
|
1c847169
|
2019-08-21T16:38:59
|
|
http: allow dummy negotiation scheme to fail to act
The dummy negotiation scheme is used for known authentication strategies
that do not wish to act. For example, when a server requests the
"Negotiate" scheme but libgit2 is not built with Negotiate support, and
will use the "dummy" strategy which will simply not act.
Instead of setting `out` to NULL and returning a successful code, return
`GIT_PASSTHROUGH` to indicate that it did not act and catch that error
code.
|
|
dceedbb8
|
2019-08-21T15:03:50
|
|
apply: Test for git_apply_to_tree failures when new files are added
Introduce an unit test to validate if git_apply_to_tree() fails when an
applied patch adds new files.
|
|
39d18fe6
|
2019-07-31T08:37:10
|
|
smart: use push_glob instead of manual filtering
The code worked under the assumption that anything under `refs/tags` are
tag objects, and all the rest would be peelable to a commit. As it is
completely valid to have tags to blobs under a non `refs/tags` ref, this
would cause failures when trying to peel a tag to a commit.
Fix the broken filtering by switching to `git_revwalk_push_glob`, which
already handles this case.
|
|
de4bc2bd
|
2019-08-20T03:29:45
|
|
apply: git_apply_to_tree fails to apply patches that add new files
git_apply_to_tree() cannot be used apply patches with new files. An attempt
to apply such a patch fails because git_apply_to_tree() tries to remove a
non-existing file from an old index.
The solution is to modify git_apply_to_tree() to git_index_remove() when the
patch states that the modified files is removed.
|
|
630127e3
|
2019-08-20T03:08:32
|
|
apply: Fix a patch corruption related to EOFNL handling
Use of apply's API can lead to an improper patch application and a corruption
of the modified file.
The issue is caused by mishandling of the end of file changes if there are
several hunks to apply. The new line character is added to a line from a wrong
hunk.
The solution is to modify apply_hunk() to add the newline character at the end
of a line from a right hunk.
|
|
071750a3
|
2019-08-15T14:18:26
|
|
cmake: move _WIN32_WINNT definitions to root
|
|
0f40e68e
|
2019-08-14T09:05:07
|
|
Merge pull request #5187 from ianhattendorf/fix/clone-whitespace
clone: don't decode URL percent encodings
|
|
08cfa43d
|
2019-08-13T18:17:11
|
|
Merge pull request #5202 from libgit2/users/ethomson/security_updates
Security updates from 0.28.3
|
|
df3f18ac
|
2019-08-05T00:32:11
|
|
changelog: include security updates
|
|
57a9ccd5
|
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.
|
|
cb1439c9
|
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.
|
|
62b80138
|
2019-08-13T09:10:10
|
|
clone: Remove whitespace ssh test
Will add later when infrastructure is configured
|