|
128230ba
|
2019-11-09T09:41:13
|
|
fileops: correct error return on p_lstat failures when mkdir
IIRC I got a strange return once from lstat, which translated in a weird
error class/message being reported. As a safety measure, enforce a -1 return in
that case.
|
|
7ce231ff
|
2019-11-05T22:44:27
|
|
patch_parse: fix segfault when header path contains whitespace only
When parsing header paths from a patch, we reject any patches with empty
paths as malformed patches. We perform the check whether a path is empty
before sanitizing it, though, which may lead to a path becoming empty
after the check, e.g. if we have trimmed whitespace. This may lead to a
segfault later when any part of our patching logic actually references
such a path, which may then be a `NULL` pointer.
Fix the issue by performing the check after sanitizing. Add tests to
catch the issue as they would have produced a segfault previosuly.
|
|
9f2732cc
|
2019-11-05T07:45:11
|
|
fix a bug introduced in 8a23597b
|
|
c32f5b00
|
2019-10-26T17:21:29
|
|
Follow 308 redirect in WinHTTP transport
|
|
|
54f0a278
|
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.
|
|
|
608cb07d
|
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.
|
|
|
db73191b
|
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.
|
|
51fb0c15
|
2019-09-10T17:09:57
|
|
open:move all cleanup code to cleanup label in git_repository_open_ext
|
|
fc60777e
|
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.
|
|
fceedda5
|
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.
|
|
|
5aca2444
|
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.
|
|
|
85ab27c8
|
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.
|
|
|
3c605da6
|
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.
|
|
|
3223f5de
|
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.
|
|
|
93dc8a04
|
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.
|
|
|
18ca62de
|
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.
|
|
|
8c99ccc5
|
2019-09-10T11:14:36
|
|
open:fix memory leak when passing NULL to git_repository_open_ext
|
|
|
35168571
|
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.
|
|
|
f647d021
|
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.
|
|
|
ad735bf3
|
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.
|
|
|
7aa03e92
|
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.
|
|
99b89a9c
|
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
|
|
|
b8339912
|
2019-07-11T12:10:48
|
|
apply: refactor to use a switch statement
|
|
5e5a9cce
|
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.
|
|
|
0126e3fc
|
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.
|
|
ae9b333a
|
2019-08-27T13:10:53
|
|
apply: free test data
|
|
|
deda897a
|
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.
|
|
|
d6e5c44f
|
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.
|
|
30cd1e1f
|
2019-08-01T20:04:11
|
|
config: check if we are running in a sandboxed environment
On macOS the $HOME environment variable returns the path to the sandbox container instead of the actual user $HOME for sandboxed apps. To get the correct path, we have to get it from the password file entry.
|
|
|
c159cceb
|
2019-07-20T18:49:48
|
|
patch_parse: fix segfault due to line containing static contents
With commit dedf70ad2 (patch_parse: do not depend on parsed buffer's
lifetime, 2019-07-05), all lines of the patch are allocated with
`strdup` to make lifetime of the parsed patch independent of the buffer
that is currently being parsed. In patch b08932824 (patch_parse: ensure
valid patch output with EOFNL, 2019-07-11), we introduced another
code location where we add lines to the parsed patch. But as that one
was implemented via a separate pull request, it wasn't converted to use
`strdup`, as well. As a consequence, we generate a segfault when trying
to deallocate the potentially static buffer that's now in some of the
lines.
Use `git__strdup` to fix the issue.
|
|
|
16dbedc9
|
2019-07-11T12:12:04
|
|
patch_parse: ensure valid patch output with EOFNL
|
|
|
fe012c60
|
2019-07-05T11:06:33
|
|
patch_parse: handle missing newline indicator in old file
When either the old or new file contents have no newline at the end of
the file, then git-diff(1) will print out a "\ No newline at end of
file" indicator. While we do correctly handle this in the case where the
new file has this indcator, we fail to parse patches where the old file
is missing a newline at EOF.
Fix this bug by handling and missing newline indicators in the old file.
Add tests to verify that we can parse such files.
|
|
|
ef1651e6
|
2019-07-11T11:34:40
|
|
diff: ignore EOFNL for computing patch IDs
The patch ID is supposed to be mostly context-insignificant and
thus only includes added or deleted lines. As such, we shouldn't honor
end-of-file-without-newline markers in diffs.
Ignore such lines to fix how we compute the patch ID for such diffs.
|
|
|
782bc334
|
2019-07-05T09:35:43
|
|
patch_parse: do not depend on parsed buffer's lifetime
When parsing a patch from a buffer, we let the patch lines point into
the original buffer. While this is efficient use of resources, this also
ties the lifetime of the parsed patch to the parsed buffer. As this
behaviour is not documented anywhere in our API it is very surprising to
its users.
Untie the lifetime by duplicating the lines into the parsed patch. Add a
test that verifies that lifetimes are indeed independent of each other.
|
|
|
7786d7e9
|
2019-06-23T20:22:29
|
|
ci: add flaky test re-execution on Windows
Our online tests are occasionally flaky since they hit real network
endpoints. Re-run them up to 5 times if they fail, to allow us to
avoid having to fail the whole build.
|
|
|
f8a09985
|
2019-06-23T19:57:05
|
|
ci: add flaky test re-execution on Unix
Our online tests are occasionally flaky since they hit real network
endpoints. Re-run them up to 5 times if they fail, to allow us to
avoid having to fail the whole build.
|
|
|
2ce6eddf
|
2019-02-21T08:30:22
|
|
tests: apply: verify that we correctly truncate the source buffer
Previously, we would fail to correctly truncate the source buffer
if the source has more than one line and ends with a non-newline
character. In the following call, we thus truncate the source
string in the middle of the second line. Without the bug fixed,
we would successfully apply the patch to the source and return
success. With the overflow being fixed, we should return an
error now.
|
|
|
6f351d83
|
2019-02-20T15:30:11
|
|
apply: prevent OOB read when parsing source buffer
When parsing the patch image from a string, we split the string
by newlines to get a line-based view of it. To split, we use
`memchr` on the buffer and limit the buffer length by the
original length provided by the caller. This works just fine for
the first line, but for every subsequent line we need to actually
subtract the amount of bytes that we have already read.
The above issue can be easily triggered by having a source buffer
with at least two lines, where the second line does _not_ end in
a newline. Given a string "foo\nb", we have an original length of
five bytes. After having extracted the first line, we will point
to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an
out-of-bounds read of four bytes.
Fix the issue by correctly subtracting the amount of bytes
already read.
|
|
|
106a5f27
|
2019-12-10T20:39:58
|
|
Merge pull request #5330 from pks-t/ethomson/v0.28.4
Security release v0.28.4
|
|
|
93be6d20
|
2019-12-10T13:45:29
|
|
version: bump version number to v0.28.4
|
|
|
245a1aa5
|
2019-12-10T13:44:27
|
|
changelog: update for security release v0.28.4
|
|
|
a673ce14
|
2019-12-03T23:15:47
|
|
path: support non-ascii drive letters on dos
Windows/DOS only supports drive letters that are alpha characters A-Z.
However, you can `subst` any one-character as a drive letter, including
numbers or even emoji. Test that we can identify emoji as drive
letters.
|
|
|
6bd07401
|
2019-12-03T19:50:18
|
|
index: ensure that we respect core.protectNTFS=false
Users may want to turn off core.protectNTFS, perhaps to import (and then
repair) a broken tree. Ensure that core.protectNTFS=false is honored.
|
|
|
0d8b9373
|
2019-12-03T23:23:02
|
|
tree: ensure we protect NTFS paths everywhere
|
|
|
50a33c30
|
2019-12-03T19:24:59
|
|
path: protect NTFS everywhere
Enable core.protectNTFS by default everywhere and in every codepath, not
just on checkout.
|
|
|
aa0902f4
|
2019-12-03T19:17:41
|
|
test: ensure we can't add a protected path
Test that when we enable core.protectNTFS that we cannot add
platform-specific invalid paths to the index.
|
|
|
f26b03d9
|
2019-12-03T19:01:00
|
|
test: improve badname verification test
The name of the `add_invalid_filename` function suggests that we
_want_ to add an invalid filename. Rename the function to show that
we expect to _fail_ to add the invalid filename.
|
|
|
94589e7c
|
2019-12-03T18:57:16
|
|
test: ensure treebuilder validate new protection rules
Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
enabled for using the treebuilder when core.protectNTFS is set.
|
|
|
fd255d2c
|
2019-12-03T18:56:31
|
|
test: ensure index adds validate new protection rules
Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
enabled for adding to the index when core.protectNTFS is set.
|
|
|
a336ed18
|
2019-12-03T18:49:23
|
|
test: improve badname verification test
The name of the `write_invalid_filename` function suggests that we
_want_ to write an invalid filename. Rename the function to show that
we expect to _fail_ to write the invalid filename.
|
|
|
f49378b6
|
2019-12-03T17:47:31
|
|
path: rename function that detects end of filename
The function `only_spaces_and_dots` used to detect the end of the
filename on win32. Now we look at spaces and dots _before_ the end of
the string _or_ a `:` character, which would signify a win32 alternate
data stream.
Thus, rename the function `ntfs_end_of_filename` to indicate that it
detects the (virtual) end of a filename, that any further characters
would be elided to the given path.
|
|
ac0b2ef1
|
2019-09-18T16:33:18
|
|
path: also guard `.gitmodules` against NTFS Alternate Data Streams
We just safe-guarded `.git` against NTFS Alternate Data Stream-related
attack vectors, and now it is time to do the same for `.gitmodules`.
Note: In the added regression test, we refrain from verifying all kinds
of variations between short names and NTFS Alternate Data Streams: as
the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it
is enough to test one in order to know that all of them are guarded
against.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
460a9fdc
|
2019-09-18T14:32:05
|
|
Disallow NTFS Alternate Data Stream attacks, even on Linux/macOS
A little-known feature of NTFS is that it offers to store metadata in
so-called "Alternate Data Streams" (inspired by Apple's "resource
forks") that are copied together with the file they are associated with.
These Alternate Data Streams can be accessed via `<file name>:<stream
name>:<stream type>`.
Directories, too, have Alternate Data Streams, and they even have a
default stream type `$INDEX_ALLOCATION`. Which means that `abc/` and
`abc::$INDEX_ALLOCATION/` are actually equivalent.
This is of course another attack vector on the Git directory that we
definitely want to prevent.
On Windows, we already do this incidentally, by disallowing colons in
file/directory names.
While it looks as if files'/directories' Alternate Data Streams are not
accessible in the Windows Subsystem for Linux, and neither via
CIFS/SMB-mounted network shares in Linux, it _is_ possible to access
them on SMB-mounted network shares on macOS.
Therefore, let's go the extra mile and prevent this particular attack
_everywhere_. To keep things simple, let's just disallow *any* Alternate
Data Stream of `.git`.
This is libgit2's variant of CVE-2019-1352.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
7bf80ab0
|
2019-09-18T15:25:02
|
|
Protect against 8.3 "short name" attacks also on Linux/macOS
The Windows Subsystem for Linux (WSL) is getting increasingly popular,
in particular because it makes it _so_ easy to run Linux software on
Windows' files, via the auto-mounted Windows drives (`C:\` is mapped to
`/mnt/c/`, no need to set that up manually).
Unfortunately, files/directories on the Windows drives can be accessed
via their _short names_, if that feature is enabled (which it is on the
`C:` drive by default).
Which means that we have to safeguard even our Linux users against the
short name attacks.
Further, while the default options of CIFS/SMB-mounts seem to disallow
accessing files on network shares via their short names on Linux/macOS,
it _is_ possible to do so with the right options.
So let's just safe-guard against short name attacks _everywhere_.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
48043516
|
2019-09-18T15:08:56
|
|
cl_git_fail: do not report bogus error message
When we expect a checkout operation to fail, but it succeeds, we
actually do not want to see the error messages that were generated in
the meantime for errors that were handled gracefully by the code (e.g.
when an object could not be found in a pack: in this case, the next
backend would have been given a chance to look up the object, and
probably would have found it because the checkout succeeded, after all).
Which means that in the specific case of `cl_git_fail()`, we actually
want to clear the global error state _after_ evaluating the command: we
know that any still-available error would be bogus, seeing as the
command succeeded (unexpectedly).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
7ce88e66
|
2019-08-05T00:12:36
|
|
Release v0.28.3
|
|
|
ee6ebcc9
|
2019-08-05T00:11:54
|
|
v0.28.3: update changelog for security release
|
|
|
3316f666
|
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.
|
|
|
d475d5d6
|
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.
|
|
|
b3e1a56e
|
2019-05-21T09:54:19
|
|
Merge pull request #5064 from pks-t/pks/v0.28.2
Release v0.28.2
|
|
0d68704a
|
2019-05-05T07:49:09
|
|
Support symlinks for directories in win32
(cherry picked from commit 37a7adb59c5075901bd64259e8a98ccef6f6f452)
|
|
|
eddd8fd1
|
2019-05-02T10:35:46
|
|
Release v0.28.2
|
|
887e004e
|
2019-05-20T12:44:37
|
|
define SYMBOLIC_LINK_FLAG_DIRECTORY if not defined
(cherry picked from commit 0fd259ed7a597c32d619190898bb5780a1ddbdd4)
|
|
|
4881a867
|
2019-05-06T14:51:52
|
|
Moved dwFlags declaration to beginning of scope
(cherry picked from commit 336e98bb95393b165bc5f13f3b729cbddf1fd554)
|
|
98c11905
|
2019-03-20T12:28:45
|
|
Correctly write to missing locked global config
Opening a default config when ~/.gitconfig doesn't exist, locking it,
and attempting to write to it causes an assertion failure.
Treat non-existent global config file content as an empty string.
(cherry picked from commit e44110dbbfc9d50b883d73fbb6c9e3b53732ec9d)
|
|
|
9e07f684
|
2019-04-26T08:01:56
|
|
cmake: fix include ordering issues with bundled deps
When linking against bundled libraries, we include their header
directories by using "-isystem". The reason for that is that we
want to handle our vendored library headers specially, most
importantly to ignore warnings generated by including them. By
using "-isystem", though, we screw up the order of searched
include directories by moving those bundled dependencies towards
the end of the lookup order. Like this, chances are high that any
other specified include directory contains a file that collides
with the actual desired include file.
Fix this by not treating the bundled dependencies' include
directories as system includes. This will move them to the front
of the lookup order and thus cause them to override
system-provided headers. While this may cause the compiler to
generate additional warnings when processing bundled headers,
this is a tradeoff we should make regardless to fix builds on
systems hitting this issue.
(cherry picked from commit ee3d71fb86bad4a681d762d90374e46f1d005714)
|
|
|
085ed2c6
|
2019-02-25T11:35:16
|
|
cmake: correctly detect if system provides `regcomp`
We assume that if we are on Win32, Amiga OS, Solaris or SunOS,
that the regcomp(3P) function cannot be provided by the system.
Thus we will in these cases always include our own, bundled regex
sources to make a regcomp implementation available. This test is
obviously very fragile, and we have seen it fail on MSYS2/MinGW
systems, which do in fact provide the regcomp symbol. The effect
is that during compilation, we will use the "regex.h" header
provided by MinGW, but use symbols provided by ourselves. This
in fact may cause subtle memory layout issues, as the structure
made available via MinGW doesn't match what our bundled code
expects.
There's one more problem with our regex detection: on the listed
platforms, we will incorrectly include the bundled regex code
even in case where the system provides regcomp_l(3), but it will
never be used for anything.
Fix the issue by improving our regcomp detection code. Instead of
relying on a fragile listing of platforms, we can just use
`CHECK_FUNCTION_EXISTS` instead. This will not in fact avoid the
header-ordering problem. But we can assume that as soon as a
system-provided "regex.h" header is provided, that
`CHECK_FUNCTION_EXISTS` will now correctly find the desired
symbol and thus not include our bundled regex code.
(cherry picked from commit 13cb9f7a3325e71a01073647d1c23f49464f200e)
|
|
4ec32d36
|
2019-04-16T18:13:31
|
|
config_file: check result of git_array_alloc
git_array_alloc can return NULL if no memory is available, causing
a segmentation fault in memset. This adds GIT_ERROR_CHECK_ALLOC
similar to how other parts of the code base deal with the return
value of git_array_alloc.
|
|
|
9b698978
|
2019-04-12T08:54:06
|
|
git_repository_init: stop traversing at windows root
Stop traversing the filesystem at the Windows directory root. We were
calculating the filesystem root for the given directory to create, and
walking up the filesystem hierarchy. We intended to stop when the
traversal path length is equal to the root path length (ie, stopping at
the root, since no path may be shorter than the root path).
However, on Windows, the root path may be specified in two different
ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter.
`git_path_dirname_r` returns the path _without_ a trailing slash, even
for the Windows root. As a result, during traversal, we need to test
that the traversal path is _less than or equal to_ the root path length
to determine if we've hit the root to ensure that we stop when our
traversal path is `Z:` and our calculated root path was `Z:\`.
|
|
|
21baf7ab
|
2019-04-05T10:22:46
|
|
ignore: treat paths with trailing "/" as directories
The function `git_ignore_path_is_ignored` is there to test the
ignore status of paths that need not necessarily exist inside of
a repository. This has the implication that for a given path, we
cannot always decide whether it references a directory or a file,
and we need to distinguish those cases because ignore rules may
treat those differently. E.g. given the following gitignore file:
*
!/**/
we'd only want to unignore directories, while keeping files
ignored. But still, calling `git_ignore_path_is_ignored("dir/")`
will say that this directory is ignored because it treats "dir/"
as a file path.
As said, the `is_ignored` function cannot always decide whether
the given path is a file or directory, and thus it may produce
wrong results in some cases. While this is unfixable in the
general case, we can do better when we are being passed a path
name with a trailing path separator (e.g. "dir/") and always
treat them as directories.
|
|
71424f63
|
2019-03-22T23:56:10
|
|
patch_parse.c: Handle CRLF in parse_header_start
|
|
|
4ec209cd
|
2019-03-29T12:30:37
|
|
tests: diff: test parsing diffs with a new file with spaces in its path
Add a test that verifies that we are able to parse patches which add a
new file that has spaces in its path.
|
|
|
96b6fe11
|
2019-03-29T12:15:20
|
|
patch_parse: fix parsing addition/deletion of file with space
The diff header format is a strange beast in that it is inherently
unparseable in an unambiguous way. While parsing
a/file.txt b/file.txt
is obvious and trivially doable, parsing a diff header of
a/file b/file ab.txt b/file b/file ab.txt
is not (but in fact valid and created by git.git).
Due to that, we have relaxed our diff header parser in commit 80226b5f6
(patch_parse: allow parsing ambiguous patch headers, 2017-09-22), so
that we started to bail out when seeing diff headers with spaces in
their file names. Instead, we try to use the "---" and "+++" lines,
which are unambiguous.
In some cases, though, we neither have a useable file name from the
header nor from the "---" or "+++" lines. This is the case when we have
a deletion or addition of a file with spaces: the header is unparseable
and the other lines will simply show "/dev/null". This trips our parsing
logic when we try to extract the prefix (the "a/" part) that is being
used in the path line, where we unconditionally try to dereference a
NULL pointer in such a scenario.
We can fix this by simply not trying to parse the prefix in cases where
we have no useable path name. That'd leave the parsed patch without
either `old_prefix` or `new_prefix` populated. But in fact such cases
are already handled by users of the patch object, which simply opt to
use the default prefixes in that case.
|
|
|
c79f9dae
|
2019-03-29T11:58:50
|
|
patch_parse: improve formatting
|
|
1df7d27a
|
2019-03-20T13:24:07
|
|
ignore: move tests from status to attr ignore suite
|
|
|
93971ca6
|
2019-03-15T13:08:18
|
|
ignore: add additional test cases
|
|
|
12bc7181
|
2019-03-14T15:51:15
|
|
ignore: Do not match on prefix of negated patterns
Matching on the prefix of a negated pattern was triggering false
negatives on siblings of that pattern. e.g.
Given the .gitignore:
dir/*
!dir/sub1/sub2/**
The path `dir/a.text` would not be ignored.
|
|
aa877e09
|
2019-03-14T09:59:27
|
|
Implement failing test for gitignore of complex subdirectory negation
When a directory's contents are ignored, and then a glob negation is made to a nested subdir, other subdirectories are now unignored
|
|
856afc27
|
2019-02-16T22:06:58
|
|
Fix a _very_ improbable memory leak in git_odb_new()
This change fixes a mostly theoretical memory leak in got_odb_new()
that can only manifest if git_cache_init() fails due to running out of
memory or not being able to acquire its lock.
|
|
|
5189beb0
|
2019-02-16T19:55:30
|
|
Fix a memory leak in odb_otype_fast()
This change frees a copy of a cached object in odb_otype_fast().
|
|
|
572e4d8c
|
2019-02-14T16:36:00
|
|
Merge pull request #4983 from libgit2/ethomson/v0_28_1
Release v0.28.1
|
|
|
65fff789
|
2019-02-14T13:37:00
|
|
Release v0.28.1
|
|
|
b8837827
|
2019-02-14T13:09:23
|
|
Merge pull request #4979 from libgit2/ethomson/deprecate
Deprecation: export the deprecated functions properly
|
|
|
3f823c2b
|
2019-02-14T00:00:06
|
|
ci: enable hard deprecation
Enable hard deprecation in our builds to ensure that we do not call
deprecated functions internally.
|
|
|
dcf81cdb
|
2019-02-13T23:56:40
|
|
deprecation: optionally enable hard deprecation
Add a CMake option to enable hard deprecation; the resultant library
will _not_ include any deprecated functions. This may be useful for
internal CI builds that create libraries that are not shared with
end-users to ensure that we do not use deprecated bits internally.
|
|
|
24ac9e0c
|
2019-02-13T23:26:54
|
|
deprecation: ensure we GIT_EXTERN deprecated funcs
Although the error functions were deprecated, we did not properly mark
them as deprecated. We need to include the `deprecated.h` file in order
to ensure that the functions get their export attributes.
Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or
those functions will also not get their export attributes. Define that
only on the tests and examples.
|
|
|
e1916376
|
2019-02-14T09:22:57
|
|
Merge pull request #4980 from libgit2/ethomson/ci_nightly
ci: skip ssh tests on macOS nightly
|
|
|
ef91917f
|
2019-02-14T09:19:32
|
|
ci: skip ssh tests on macOS nightly
Like 811c1c0f8f80521dccc746a7bff180cd77a783ff, disable the SSH tests on
macOS until we can resolve the newly introduced infrastructure issues.
|
|
|
85b2bd41
|
2019-02-14T01:13:33
|
|
Merge pull request #4976 from libgit2/ethomson/readme_v028
CI build fixups
|
|
|
811c1c0f
|
2019-02-14T00:51:39
|
|
ci: skip ssh tests on macOS
SSH tests on macOS have begun failing for an unknown reason after an
infrastructure upgrade to macOS 10.13.6. Disable those tests
temporarily, until we can resolve it.
|
|
|
44f82134
|
2019-02-13T11:18:35
|
|
ci: provide more information about OS
Subtle changes in the host OS can have impacts in the CI system that
may be hard to debug. We previously showed the results of `uname` which
can be difficult to interpret. Provide more information where
available.
|
|
|
6f778351
|
2019-02-13T11:15:12
|
|
README: use correct badge for nightlies
The URL was incorrect for the nightly badge image; it was erroneously
showing the master branch continuous integration build badge.
|
|
|
f34faaa8
|
2019-02-12T16:45:57
|
|
README: include build badge for v0.28 builds
Include a build badge for `maint/v0.28` builds.
|
|
|
1a107fac
|
2019-02-02T10:25:54
|
|
Merge pull request #4970 from libgit2/ethomson/0_28
v0.28 rc1
|
|
|
3fe29c4d
|
2019-01-31T19:10:03
|
|
version: 0.28
|
|
|
63f96cd0
|
2019-01-31T19:09:42
|
|
changelog: this is 0.28
|
|
|
214457c6
|
2019-01-31T18:51:36
|
|
Merge pull request #4968 from tiennou/fix/documentation
Docs
|
|
|
6853a250
|
2019-01-31T14:46:21
|
|
Merge branch 'pks/stream-truncated-writes'
|
|
|
0ceac0d0
|
2019-01-23T14:45:19
|
|
mbedtls: fix potential size overflow when reading or writing data
The mbedtls library uses a callback mechanism to allow downstream users
to plug in their own receive and send functions. We implement `bio_read`
and `bio_write` functions, which simply wrap the `git_stream_read` and
`git_stream_write` functions, respectively.
The problem arises due to the return value of the callback functions:
mbedtls expects us to return an `int` containing the actual number of
bytes that were read or written. But this is in fact completely
misdesigned, as callers are allowed to pass in a buffer with length
`SIZE_MAX`. We thus may be unable to represent the number of bytes
written via the return value.
Fix this by only ever reading or writing at most `INT_MAX` bytes.
|
|
|
75918aba
|
2019-01-23T14:43:54
|
|
mbedtls: make global variables static
The mbedtls stream implementation makes use of some global variables
which are not marked as `static`, even though they're only used in this
compilation unit. Fix this and remove a duplicate declaration.
|