|
cd5e33fb
|
2019-11-06T11:08:23
|
|
global: DRY includes of assert.h
|
|
c2749849
|
2019-10-24T12:00:11
|
|
config_file: rename function names
As with the predecessing commit, this commit renames backend functions
of the configuration file backend. This helps to clearly separate
functionality and also to be able to see from backtraces which backend
is currently in use.
|
|
|
56b203a5
|
2019-10-24T12:20:27
|
|
config_file: keep reference to config entries when creating iterator
When creating a configuration file iterator, then we first refresh the
backend and then afterwards duplicate all refreshed configuration
entries into the iterator in order to avoid seeing any concurrent
modifications of the entries while iterating. The duplication of entries
is not guarded, though, as we do not increase the refcount of the
entries that we duplicate right now. This opens us up for a race, as
another thread may concurrently refresh the repository configuration and
thus swap out the current set of entries. As we didn't increase the
refcount, this may lead to the entries being free'd while we iterate
over them in the first thread.
Fix the issue by properly handling the lifecycle of the backend's
entries via `config_file_entries_take` and `git_config_entries_free`,
respectively.
|
|
|
0927156a
|
2019-10-24T12:32:11
|
|
config_file: refactor taking entries ref to return an error code
The function to take a reference to the config file's config entries
currently returns the reference via return value. Due to this, it's
harder than necessary to integrate into our typical coding style, as one
needs to make sure that a proper error code is set before erroring out
from the caller. This bites us in `config_file_delete`, where we call
`goto out` directly when `config_file_entries_take` returns `NULL`, but
we actually forget to set up the error code and thus return success.
Fix the issue by refactoring the function to return an error code and
pass the reference via an out-pointer.
|
|
|
db301087
|
2019-10-24T12:17:02
|
|
config_file: remove unused includes
|
|
|
b30b04a9
|
2019-11-05T12:34:14
|
|
config_snapshot: rename function names
The configuration snapshot backend has been extracted from the old files
backend back in 2bff84ba4 (config_file: separate out read-only backend,
2019-07-26). To keep code churn manageable, the local functions weren't
renamed yet and thus still have references to the old diskfile backend.
Rename them accordingly to make them easier to understand.
|
|
|
82d7a114
|
2019-11-05T11:18:14
|
|
Merge pull request #5293 from csware/config_snapshot-snapshot
Fix crash if snapshotting a config_snapshot
|
|
1886478d
|
2019-11-05T07:45:11
|
|
fix a bug introduced in 8a23597b
|
|
bf2911d7
|
2019-11-02T07:30:32
|
|
Merge pull request #5275 from pks-t/pks/reflogs-with-newlines
reflogs: fix behaviour around reflogs with newlines
|
|
dadbb33b
|
2019-11-01T18:55:54
|
|
Fix crash if snapshotting a config_snapshot
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
718f24ad
|
2019-10-30T20:39:03
|
|
commit: verify objects exist in git_commit_with_signature
There can be a significant difference between the system where we created the
buffer (if at all) and when the caller provides us with the contents of a
commit.
Verify that the commit we are being asked to create references objects which do
exist in the target repository.
|
|
|
2a7d6de3
|
2019-10-29T07:52:31
|
|
Merge pull request #5276 from pks-t/pks/patch-fuzzing-fixes
patch_parse: fixes for fuzzing errors
|
|
|
a31f4c4b
|
2019-10-24T13:16:03
|
|
Merge pull request #5227 from ddevault/check
apply: add GIT_APPLY_CHECK
|
|
|
c405f231
|
2019-10-24T10:26:43
|
|
Merge pull request #5264 from henkesn/refs-unlock-on-commit
refs: unlock unmodified refs on transaction commit
|
|
02af1fcb
|
2019-09-14T14:03:36
|
|
apply: add GIT_APPLY_CHECK
This adds an option which will check if a diff is applicable without
actually applying it; equivalent to git apply --check.
|
|
|
37141ff7
|
2019-10-21T18:56:59
|
|
patch_parse: detect overflow when calculating old/new line position
When the patch contains lines close to INT_MAX, then it may happen that
we end up with an integer overflow when calculating the line of the
current diff hunk. Reject such patches as unreasonable to avoid the
integer overflow.
As the calculation is performed on integers, we introduce two new
helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform
the integer overflow check in a generic way.
|
|
|
468e3ddc
|
2019-10-19T16:48:11
|
|
patch_parse: fix out-of-bounds read with No-NL lines
We've got two locations where we copy lines into the patch. The first
one is when copying normal " ", "-" or "+" lines, while the second
location gets executed when we copy "\ No newline at end of file" lines.
While the first one correctly uses `git__strndup` to copy only until the
newline, the other one doesn't. Thus, if the line occurs at the end of
the patch and if there is no terminating NUL character, then it may
result in an out-of-bounds read.
Fix the issue by using `git__strndup`, as was already done in the other
location. Furthermore, add allocation checks to both locations to detect
out-of-memory situations.
|
|
|
6c6c15e9
|
2019-10-19T15:52:35
|
|
patch_parse: reject empty path names
When parsing patch headers, we currently accept empty path names just
fine, e.g. a line "--- \n" would be parsed as the empty filename. This
is not a valid patch format and may cause `NULL` pointer accesses at a
later place as `git_buf_detach` will return `NULL` in that case.
Reject such patches as malformed with a nice error message.
|
|
|
223e7e43
|
2019-10-19T15:42:54
|
|
patch_parse: reject patches with multiple old/new paths
It's currently possible to have patches with multiple old path name
headers. As we didn't check for this case, this resulted in a memory
leak when overwriting the old old path with the new old path because we
simply discarded the old pointer.
Instead of fixing this by free'ing the old pointer, we should reject
such patches altogether. It doesn't make any sense for the "---" or
"+++" markers to occur multiple times within a patch n the first place.
This also implicitly fixes the memory leak.
|
|
|
7968e90f
|
2019-10-18T12:33:07
|
|
refdb_fs: properly parse corrupted reflogs
In previous versions, libgit2 could be coerced into writing reflog
messages with embedded newlines into the reflog by using
`git_stash_save` with a message containing newlines. While the root
cause is fixed now, it was noticed that upstream git is in fact able to
read such corrupted reflog messages just fine.
Make the reflog parser more lenient in order to just skip over
malformatted reflog lines to bring us in line with git. This requires us
to change an existing test that verified that we do indeed _fail_ to
parse such logs.
|
|
|
8532ed11
|
2019-10-18T12:14:19
|
|
refdb_fs: convert reflog parsing to use parser
The refdb_fs code to parse the reflog currently uses a hand-rolled
parser. Convert it to use our `git_parse_ctx` structure instead.
|
|
|
d8233feb
|
2019-10-18T09:24:14
|
|
reflog: allow adding entries with newlines in their message
Currently, the reflog disallows any entries that have a message with
newlines, as that would effectively break the reflog format, which may
contain a single line per entry, only. Upstream git behaves a bit
differently, though, especially when considering stashes: instead of
rejecting any reflog entry with newlines, git will simply replace
newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will
create a reflog entry with "foo bar" as entry message.
This commit adjusts our own logic to stop rejecting commit messages with
newlines. Previously, this logic was part of `git_reflog_append`, only.
There is a second place though where we add reflog entries, which is the
serialization code in the filesystem refdb. As it didn't contain any
sanity checks whatsoever, the refdb would have been perfectly happy to
write malformatted reflog entries to the disk. This is being fixed with
the same logic as for the reflog itself.
|
|
|
28481609
|
2019-10-18T09:41:20
|
|
stash: refactor code that prepares commit messages
|
|
|
ca2d34a8
|
2019-10-18T09:06:48
|
|
stash: modernize code style of `git_stash_save`
The code style of `git_stash_save` doesn't really match our current
coding style. Update it to match our current policies more closely.
|
|
|
c9464bf7
|
2019-10-17T18:33:12
|
|
Merge pull request #5273 from dlax/parse-diff-without-extended-headers
patch_parse: handle patches without extended headers
|
|
47531f47
|
2019-10-11T12:44:09
|
|
refs: unlock unmodified refs on transaction commit
Refs which are locked in a transaction without an altered target,
still should to be unlocked on `git_transaction_commit`.
`git_transaction_free` also unlocks refs but the moment of calling of `git_transaction_free`
cannot be controlled in all situations.
Some binding libs call `git_transaction_free` on garbage collection or not at all if the
application exits before and don't provide public access to `git_transaction_free`.
It is better to release locks as soon as possible.
|
|
|
3c5d78bd
|
2019-05-01T16:16:26
|
|
submodule: provide a wrapper for simple submodule clone steps
|
|
11de594f
|
2019-10-16T22:11:33
|
|
patch_parse: handle patches without extended headers
Extended header lines (especially the "index <hash>..<hash> <mode>") are
not required by "git apply" so it import patches. So we allow the
from-file/to-file lines (--- a/file\n+++ b/file) to directly follow the
git diff header.
This fixes #5267.
|
|
|
dbc17a7e
|
2019-09-21T08:46:08
|
|
negotiate: use GSS.framework on macOS
|
|
|
0eecb660
|
2019-10-13T13:53:18
|
|
cmake: remove extra GIT_NTLM define
|
|
|
aa234ac0
|
2019-09-21T08:47:01
|
|
util: hide helper qsort code to silence unused functions warning
|
|
|
ef5a3851
|
2019-10-11T07:47:17
|
|
Merge pull request #5257 from henkesn/master
Fix file locking on POSIX OS
|
|
|
1f9b4970
|
2019-10-11T07:44:10
|
|
Merge pull request #5260 from pks-t/pks/cmake3
cmake: update minimum CMake version to v3.5.1
|
|
|
3335a034
|
2019-10-10T15:28:46
|
|
refs: fix locks getting forcibly removed
The flag GIT_FILEBUF_FORCE currently does two things:
1. It will cause the filebuf to create non-existing leading
directories for the file that is about to be written.
2. It will forcibly remove any pre-existing locks.
While most call sites actually do want (1), they do not want to
remove pre-existing locks, as that renders the locking mechanisms
effectively useless.
Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to
separate both behaviours cleanly from each other and convert
callers to use it instead of `GIT_FILEBUF_FORCE` to have them
honor locked files correctly.
As this conversion removes all current users of `GIT_FILEBUF_FORCE`,
this commit removes the flag altogether.
|
|
|
6716e2f3
|
2019-10-10T12:34:45
|
|
Merge pull request #5248 from dlax/parse-patch-empty-files
patch_parse: handle patches with new empty files
|
|
|
ebabb88f
|
2019-10-10T09:25:32
|
|
cmake: update minimum CMake version to v3.5.1
Back in commit cf9f34521 (cmake: bump minimum version to 2.8.11,
2017-09-06), we have bumped the minimum CMake version to require at
least v2.8.11. The main hold-backs back then were distributions like
RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a
more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6
has CMake v3.6.1 available via the EPEL6 repository, and thus it seems
fair to upgrade to a more recent version.
Going through repology [1], one can see that all supported mainstream
distributions do in fact have CMake 3 available. Going through the list,
the minimum version that is supported by all mainstream distros is in
fact v3.5.1:
- CentOS 6 via EPEL6: 3.6.1
- Debian Oldstable: 3.7.2
- Fedora 26: 3.8.2
- OpenMandriva 3.x: 3.5.1
- Slackware 14.2: 3.5.2
- Ubuntu 16.04: 3.5.1
Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and
remove all the version CMake checks that aren't required anymore.
[1]: https://repology.org/project/cmake/versions
|
|
|
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.
|
|
|
63307cba
|
2019-09-28T17:32:18
|
|
Merge pull request #5226 from pks-t/pks/regexp-api
regexp: implement a new regular expression API
|
|
|
b61810bf
|
2019-09-28T15:52:25
|
|
patch_parse: handle patches with new empty files
Patches containing additions of empty files will not contain diff data
but will end with the index header line followed by the terminating
sequence "-- ". We follow the same logic as in cc4c44a and allow "-- "
to immediately follow the index header.
|
|
|
70325370
|
2019-09-27T11:16:02
|
|
Merge pull request #5106 from tiennou/fix/ref-api-fixes
git_refdb API fixes
|
|
|
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>
|
|
|
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
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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
|
|
|
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
|
|
|
8bf0f7eb
|
2019-09-09T13:00:27
|
|
cred: separate public interface from low-level details
|
|
|
5d8a4659
|
2019-09-13T10:31:49
|
|
Merge pull request #5195 from tiennou/fix/commitish-smart-push
smart: use push_glob instead of manual filtering
|
|
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
|
|
|
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
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
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
|
|
|
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.
|