|
219512e7
|
2018-07-20T14:14:16
|
|
buf tests: allocate a smaller size for the oom
On Linux (where we run valgrind) allocate a smaller buffer, but still an
insanely large size. This will cause malloc to fail but will not cause
valgrind to report a likely error with a negative-sized malloc.
Keep the original buffer size on non-Linux platforms: this is
well-tested on them and changing it may be problematic. On macOS, for
example, using the new size causes `malloc` to print a warning to
stderr.
|
|
|
ce798b25
|
2018-07-04T10:56:56
|
|
tests: simplify cmake test configuration
Simplify the names for the tests, removing the unnecessary
"libgit2-clar" prefix. Make "all" the new default test run, and include
the online tests by default (since HTTPS should always be enabled).
For the CI tests, create an offline-only test, then the various online
tests.
|
|
|
d285de73
|
2018-07-20T21:52:24
|
|
push tests: deeply free the specs
Don't just free the spec vector, also free the specs themselves.
|
|
|
dad99881
|
2018-07-20T21:51:36
|
|
push tests: deeply free the push status
Don't just free the push status structure, actually free the strings that were
strdup'd into the struct as well.
|
|
0652abaa
|
2018-07-20T12:56:49
|
|
Merge pull request #4702 from tiennou/fix/coverity
Assorted Coverity fixes
|
|
|
e1a4a8eb
|
2018-06-25T11:58:34
|
|
cmake: enforce C90 standard
While the aim of libgit2 was to conform to C90 code, we never instructed
the compiler to enforce C90 compliance. Thus, quite a few violations
were able to get into our code base, which have been removed with the
previous commits. As we are now able to build libgit2 with C90 enforced,
we can set the C_STANDARD property for our own build targets.
Note that we explicitly avoid setting the C standard for our third-party
dependencies. At least the zlib target does not build with C90 enforced,
and we do not want to fix them by deviating from upstream. Thus we
simply enforce no standard for them.
|
|
|
c13e56f9
|
2018-06-25T14:12:53
|
|
cmake: distinguish internal and system include directories
While we want to enforce strict C90 mode, this may cause issues with
system provided header files which are themselves not strictly
conforming. E.g. if a system header has C++ style comments, a compiler
in strict C90 mode would produce an error and abort the build. As the
user most likely doesn't want to change the system header, this would
completely break the build on such systems. One example of this is
mbedtls, which provides such header files.
The problem can be worked around by distinguishing between
system-provided and project-provided include directories. When adding
include directories via "-isystem" instead of "-I", the compiler will
skip certain checks and print out less warnings. To use system includes,
we can simply add the "SYSTEM" flag to CMake's `INCLUDE_DIRECTORIES` and
`TARGET_INCLUDE_DIRECTORIES` functions. Note that we have to split the
include directories into two variables because of this, as we definitely
still want to check for all warnings produced by our own header files.
|
|
|
9994cd3f
|
2018-06-25T11:56:52
|
|
treewide: remove use of C++ style comments
C++ style comment ("//") are not specified by the ISO C90 standard and
thus do not conform to it. While libgit2 aims to conform to C90, we did
not enforce it until now, which is why quite a lot of these
non-conforming comments have snuck into our codebase. Do a tree-wide
conversion of all C++ style comments to the supported C style comments
to allow us enforcing strict C90 compliance in a later commit.
|
|
|
6dfc8bc2
|
2018-07-09T23:10:05
|
|
Merge pull request #4719 from pks-t/pks/delta-oob
Delta OOB access
|
|
89091d36
|
2018-07-06T20:24:21
|
|
tests: fix a relative pathname issue
The path given to `git_index_add_bypath` is relative to the root of the
repository. That `describe/file` path is relative to the root of the
sandbox directory, hence if I add the missing `cl_git_pass` I rightfully
get an error that `$SANDBOX/describe/describe/file doesn't exist`.
The path is thus changed to be made relative to the repository, which
makes the failure go away and "restore" the test.
|
|
|
8455a270
|
2018-07-01T12:04:27
|
|
tests: add missing cl_git_pass to tests
Reported by Coverity, CID 1393678-1393697.
|
|
|
17bd3b96
|
2018-06-19T20:15:49
|
|
tests: mailmap/parsing: add a missing cl_git_pass
Reported by Coverity, CID 1393483
|
|
|
f4633791
|
2018-07-06T12:36:05
|
|
Merge pull request #4687 from tiennou/fix/4672
patch_parse: populate line numbers while parsing diffs
|
|
|
f2a1cece
|
2018-07-06T11:25:47
|
|
Merge pull request #4686 from tiennou/fix/more-worktree-from-bare
Fix git_worktree_validate failing on bare repositories
|
|
|
8a00de08
|
2018-07-06T10:47:06
|
|
Merge pull request #4699 from nelhage/fetch-null-dst
git_refspec_transform: Handle NULL dst
|
|
|
c43658f6
|
2018-06-30T13:24:23
|
|
Merge pull request #4536 from libgit2/ethomson/index_dirty
Add a "dirty" state to the index when it has unsaved changes
|
|
ff8edac9
|
2018-06-29T16:18:36
|
|
formatting fix
|
|
|
bfa1f022
|
2018-06-22T19:17:08
|
|
settings: optional unsaved index safety
Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause
commands that reload the on-disk index to fail if the current
`git_index` has changed that have not been saved. This will prevent
users from - for example - adding a file to the index then calling a
function like `git_checkout` and having that file be silently removed
from the index since it was re-read from disk.
Now calls that would re-read the index will fail if the index is
"dirty", meaning changes have been made to it but have not been written.
Users can either `git_index_read` to discard those changes explicitly,
or `git_index_write` to write them.
|
|
|
787768c2
|
2018-06-22T19:07:54
|
|
index: return a unique error code on dirty index
When the index is dirty, return GIT_EINDEXDIRTY so that consumers can
identify the exact problem programatically.
|
|
|
5e26391a
|
2018-06-18T18:28:08
|
|
checkout: FORCE doesn't halt on dirty index
If the index is dirty, allow `GIT_CHECKOUT_FORCE` to obliterate unsaved
changes. This is in keeping with its name and description.
|
|
|
b242cdbf
|
2017-11-17T00:19:07
|
|
index: commit the changes to the index properly
Now that the index has a "dirty" state, where it has changes that have
not yet been committed or rolled back, our tests need to be adapted to
actually commit or rollback the changes instead of assuming that the
index can be operated on in its indeterminate state.
|
|
|
dc4a18c7
|
2017-11-12T08:23:13
|
|
index: test dirty index bit
Test that any changes to the index will mark the index as dirty. Also
ensure that when we initialize a new index, read the index contents
from disk, or write the index contents to disk that we reset the dirty
flag to zero. Further ensure that an unforced read with dirty contents
(when the on-disk index has not changed) does _not_ reset the dirty
flag as we have not updated the contents of our index and our unsaved
contents remain intact.
|
|
|
55a96606
|
2018-06-18T16:14:26
|
|
checkout tests: validate GIT_CHECKOUT_NO_REFRESH
Add tests that ensure that we re-read the on-disk image by default
during checkout, but when the `GIT_CHECKOUT_NO_REFRESH` option is
specified, we do _not_ re-read the index.
|
|
|
8356bf7e
|
2018-06-29T14:39:14
|
|
tests: worktree/bare: test some paths
|
|
|
d0921127
|
2018-06-29T14:39:13
|
|
tests: add a helper to build sandbox subpaths quickly
|
|
|
83c35f7e
|
2018-06-29T14:39:11
|
|
tests: worktree/bare: fix git_worktree_validate
|
|
|
bd40f0d7
|
2018-06-29T14:39:10
|
|
tests: worktree/bare: check git_worktree_list
|
|
|
7e3c13e0
|
2018-06-29T14:39:08
|
|
tests: worktree/bare: gather all tests
|
|
|
af3088e4
|
2018-06-29T11:45:15
|
|
refspec: rename `git_refspec__free` to `git_refspec__dispose`
Since commit 630a67366 (refspec: add public parsing api, 2018-02-07), we
now have two functions `git_refspec_free` and `git_refspec__free`. The
difference is that the first one will free the structure itself, while
the second one will only free the structure's contents. Use our new
`dispose` naming pattern for the latter function to help avoid
confusion.
|
|
|
7192e26f
|
2018-06-29T09:43:33
|
|
Merge pull request #4519 from cynecx/refspec-parsing
refspec: add public parsing api
|
|
|
24597812
|
2018-06-29T09:11:02
|
|
delta: fix out-of-bounds read of delta
When computing the offset and length of the delta base, we repeatedly
increment the `delta` pointer without checking whether we have advanced
past its end already, which can thus result in an out-of-bounds read.
Fix this by repeatedly checking whether we have reached the end. Add a
test which would cause Valgrind to produce an error.
Reported-by: Riccardo Schirone <rschiron@redhat.com>
Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
|
|
|
7db25870
|
2018-06-29T07:45:18
|
|
delta: fix sign-extension of big left-shift
Our delta code was originally adapted from JGit, which itself adapted it
from git itself. Due to this heritage, we inherited a bug from git.git
in how we compute the delta offset, which was fixed upstream in
48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As
explained by Linus:
Shifting 'unsigned char' or 'unsigned short' left can result in sign
extension errors, since the C integer promotion rules means that the
unsigned char/short will get implicitly promoted to a signed 'int' due to
the shift (or due to other operations).
This normally doesn't matter, but if you shift things up sufficiently, it
will now set the sign bit in 'int', and a subsequent cast to a bigger type
(eg 'long' or 'unsigned long') will now sign-extend the value despite the
original expression being unsigned.
One example of this would be something like
unsigned long size;
unsigned char c;
size += c << 24;
where despite all the variables being unsigned, 'c << 24' ends up being a
signed entity, and will get sign-extended when then doing the addition in
an 'unsigned long' type.
Since git uses 'unsigned char' pointers extensively, we actually have this
bug in a couple of places.
In our delta code, we inherited such a bogus shift when computing the
offset at which the delta base is to be found. Due to the sign extension
we can end up with an offset where all the bits are set. This can allow
an arbitrary memory read, as the addition in `base_len < off + len` can
now overflow if `off` has all its bits set.
Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned
integer again. Add a test with a crafted delta that would actually
succeed with an out-of-bounds read in case where the cast wouldn't
exist.
Reported-by: Riccardo Schirone <rschiron@redhat.com>
Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
|
|
|
7330ae67
|
2018-06-26T10:45:57
|
|
index::addall tests: write the index
When running `git_index_add_all`, we should write the index to disk so
that we can re-read it safely during status.
|
|
|
08ea0d7d
|
2018-02-18T11:49:08
|
|
index::reuc tests: test that checkout succeeds
The index::reuc tests must test that the checkout itself succeeds,
otherwise subsequent tests are not valid.
In fact, the checkouts were failing because when checking out `SAFE`,
they cannot update the files that are in conflict. Change the checkout
level to `FORCE` to ensure that they get updated correctly.
|
|
|
c4ce017f
|
2018-02-18T22:27:34
|
|
index::names tests: add conflicts with high stages
We add entries into the main index to correspond with the NAME entries
that we're going to test. NAME entries store the results of conflicts
occuring with rename detection during merge, and they must correspond to
conflicts in the index.
This test was mistakenly adding regular entries. The checkout
validation failed, since it requires NAME entries to correspond to
high-stage (conflict) entries. Correct the test to actually create
conflicts.
|
|
|
46c9f26f
|
2018-06-25T15:47:31
|
|
Add a test.
Verified that this breaks before the fix and passes afterwards.
|
|
4fd81c53
|
2018-06-18T19:43:53
|
|
Clear revwalk sorting when resetting
Currently we fail to clear the sorting flag for revwalks when resetting.
This caused a poor interaction with the limited flag during a recent
patch. This patch clears the revwalk sorting flag and causes it to no
longer persist over resets.
|
|
630a6736
|
2018-02-07T22:30:27
|
|
refspec: add public parsing api
Fix typo
Fix some type issues
More fixes
Address requested changes
Add test
Fix naming
Fix condition and tests
Address requested changes
Fix typo
|
|
|
f9e28026
|
2018-06-18T20:37:18
|
|
patch_parse: populate line numbers while parsing diffs
|
|
b5818dda
|
2018-06-18T13:05:08
|
|
Fix last references to deprecated git_buf_free
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
|
f98131be
|
2018-06-17T00:40:25
|
|
Require the length argument to git_mailmap_from_buffer and make mailmap_add_buffer internal
|
|
|
9faf36a6
|
2018-06-14T22:48:58
|
|
mailmap: git_buf_free => git_buf_dispose
|
|
|
56303e1a
|
2018-05-07T11:59:00
|
|
mailmap: API and style cleanup
|
|
|
a140c138
|
2018-04-08T03:01:37
|
|
mailmap: Updates tests for new API and features
|
|
|
18ff9bab
|
2018-03-27T22:48:03
|
|
mailmap: API and style cleanup
|
|
|
57cfeab9
|
2018-03-26T15:05:37
|
|
mailmap: Switch mailmap parsing to use the git_parse module
|
|
|
aa3a24a4
|
2018-03-26T14:44:15
|
|
mailmap: Clean up the mailmap fixture's .gitted directory
|
|
5c6c8a9b
|
2018-03-18T01:26:30
|
|
mailmap: Fix some other minor style nits
|
|
|
4ff44be8
|
2018-03-17T18:24:15
|
|
mailmap: Fix more bugs which snuck in when I rebased
|
|
|
983b8c2d
|
2018-03-17T18:15:41
|
|
mailmap: Add a bunch of tests for the new mailmap functionality
|
|
|
939d8d57
|
2018-03-17T18:14:03
|
|
mailmap: Support path fixtures in cl_git_repository_init()
|
|
|
b88cbf8c
|
2018-03-18T01:40:47
|
|
mailmap: Add some super-basic tests
|
|
|
3be73011
|
2018-06-11T18:26:22
|
|
Merge pull request #4436 from pks-t/pks/packfile-stream-free
pack: rename `git_packfile_stream_free`
|
|
|
96212813
|
2018-06-11T17:11:36
|
|
stash test: free the commit
|
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
|
123f01f0
|
2018-06-10T12:21:43
|
|
stash test: free the reference
|
|
|
795a5b28
|
2018-06-09T18:36:21
|
|
Merge pull request #4668 from novalis/bad-stash
Fix stash save bug with fast path index check
|
|
|
44788c96
|
2018-06-09T18:00:23
|
|
Merge pull request #4662 from pks-t/pks/gitfile-api
path: unify `git_path_is_*` APIs
|
|
|
bc0f3227
|
2018-06-09T17:59:46
|
|
Merge pull request #4670 from pks-t/pks/ignore-leadingdir
Fix negative gitignore rules with leading directories
|
|
|
9865cd16
|
2018-03-20T14:23:49
|
|
alloc: make memory allocators use function pointers
Currently, our memory allocators are being redirected to the correct
implementation at compile time by simply using macros. In order to make
them swappable at runtime, this commit reshuffles that by instead making
use of a global "git_allocator" structure, whose pointers are set up to
reference the allocator functions. Like this, it becomes easy to swap
out allocators by simply setting these function pointers.
In order to initialize a "git_allocator", our provided allocators
"stdalloc" and "crtdbg" both provide an init function. This is being
called to initialize a passed in allocator struct and set up its members
correctly.
No support is yet included to enable users of libgit2 to switch out the
memory allocator at a global level.
|
|
5a7d454b
|
2018-06-04T12:56:08
|
|
Fix stash save bug with fast path index check
If the index contains stat data for a modified file, and the file is
not racily dirty, and there exists an untracked working tree directory
alphabetically after that file, and there are no other changes to the
repo, then git_stash_save would fail. It would confuse the untracked
working tree directory for the modified file, because they have the
same sha: zero. The wt directory has a sha of zero because it's a
directory, and the file would have a zero sha because we wouldn't read
the file -- we would just know that it doesn't match the index. To
fix this confusion, we simply check mode as well as SHA.
|
|
|
20306d36
|
2018-06-06T14:31:28
|
|
Merge pull request #4665 from neithernut/fix-refdb-glob
refdb_fs: fix regression: failure when globbing for non-existant references
|
|
|
8178c70f
|
2018-06-06T09:23:01
|
|
tests: submodule: do not rely on config iteration order
The test submodule::lookup::duplicated_path, which tries to verify that
we detect submodules with duplicated paths, currently relies on the
gitmodules file of "submod2_target". While this file has two gitmodules
with the same path, one of these gitmodules has an empty name and thus
does not pass `git_submodule_name_is_valid`. Because of this, the test
is in fact dependent on the iteration order in which we process the
submodules. In fact the "valid" submodule comes first, the "invalid"
submodule will cause the desired error. In fact the "invalid" submodule
comes first, it will be skipped due to its name being invalid, and we
will not see the desired error. While this works on the master branch
just right due to the refactoring of our config code, where iteration
order is now deterministic, this breaks on all older maintenance
branches.
Fix the issue by simply using `cl_git_rewritefile` to rewrite the
gitmodules file. This greatly simplifies the test and also makes the
intentions of it much clearer.
|
|
|
20b4c175
|
2018-06-05T16:12:58
|
|
ignore: fix negative leading directory rules unignoring subdirectory files
When computing whether a file is ignored, we simply search for the first
matching rule and return whether it is a positive ignore rule (the file
is really ignored) or whether it is a negative ignore rule (the file is
being unignored). Each rule has a set of flags which are being passed to
`fnmatch`, depending on what kind of rule it is. E.g. in case it is a
negative ignore we add a flag `GIT_ATTR_FNMATCH_NEGATIVE`, in case it
contains a glob we set the `GIT_ATTR_FNMATCH_HASGLOB` flag.
One of these flags is the `GIT_ATTR_FNMATCH_LEADINGDIR` flag, which is
always set in case the pattern has a trailing "/*" or in case the
pattern is negative. The flag causes the `fnmatch` function to return a
match in case a string is a leading directory of another, e.g. "dir/"
matches "dir/foo/bar.c". In case of negative patterns, this is wrong in
certain cases.
Take the following simple example of a gitignore:
dir/
!dir/
The `LEADINGDIR` flag causes "!dir/" to match "dir/foo/bar.c", and we
correctly unignore the directory. But take this example:
*.test
!dir/*
We expect everything in "dir/" to be unignored, but e.g. a file in a
subdirectory of dir should be ignored, as the "*" does not cross
directory hierarchies. With `LEADINGDIR`, though, we would just see that
"dir/" matches and return that the file is unignored, even if it is
contained in a subdirectory. Instead, we want to ignore leading
directories here and check "*.test". Afterwards, we have to iterate up
to the parent directory and do the same checks.
To fix the issue, disallow matching against leading directories in
gitignore files. This can be trivially done by just adding the
`GIT_ATTR_FNMATCH_NOLEADINGDIR` to the spec passed to
`git_attr_fnmatch__parse`. Due to a bug in that function, though, this
flag is being ignored for negative patterns, which is fixed in this
commit, as well. As a last fix, we need to ignore rules that are
supposed to match a directory when our path itself is a file.
All together, these changes fix the described error case.
|
|
|
9beb73ed
|
2018-06-05T16:45:23
|
|
tests: status::ignore: fix style of a test
|
|
d7eca4c3
|
2018-06-01T08:57:17
|
|
refdb_fs: add test for globbing of nonexistant refs
|
|
|
92159bd4
|
2018-05-30T12:18:04
|
|
path: unify `git_path_is_*` APIs
Right now, there's quite a lot of different function calls to determine
whether a path component matches a specific name after normalization
from the filesystem. We have a function for each of {gitattributes,
gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks.
In the long time, this is unmaintainable in case there are e.g. new
filesystems with specific semantics, blowing up the number of functions
we need to implement.
Replace all functions with a simple `git_path_is_gitfile` function,
which accepts an enum pointing out the filename that is to be checked
against as well as the filesystem normalizations to check for. This
greatly simplifies implementation at the expense of the caller having to
invoke a somewhat longer function call.
|
|
|
b2a389c8
|
2018-05-30T08:35:06
|
|
submodule: detect duplicated submodule paths
When loading submodule names, we build a map of submodule paths and
their respective names. While looping over the configuration keys,
we do not check though whether a submodule path was seen already. This
leads to a memory leak in case we have multiple submodules with the same
path, as we just overwrite the old value in the map in that case.
Fix the error by verifying that the path to be added is not yet part of
the string map. Git does not allow to have multiple submodules for a
path anyway, so we now do the same and detect this duplication,
reporting it to the user.
|
|
7f6c1ce9
|
2018-05-29T21:04:39
|
|
Merge pull request #4660 from libgit2/cmn/submodule-traversal
Fixes for CVE 2018-11235
|
|
57e343d7
|
2018-05-24T21:58:40
|
|
path: hand-code the zero-width joiner as UTF-8
|
|
|
9e723db8
|
2018-05-24T20:28:36
|
|
submodule: plug leaks from the escape detection
|
|
|
3fbfae26
|
2018-05-22T20:37:23
|
|
checkout: change symlinked .gitmodules file test to expect failure
When dealing with `core.proectNTFS` and `core.protectHFS` we do check
against `.gitmodules` but we still have a failing test as the non-filesystem
codepath does not check for it.
|
|
|
a7168b47
|
2018-05-22T16:13:47
|
|
path: reject .gitmodules as a symlink
Any part of the library which asks the question can pass in the mode to have it
checked against `.gitmodules` being a symlink.
This is particularly relevant for adding entries to the index from the worktree
and for checking out files.
|
|
|
02c80ad7
|
2018-05-22T15:21:08
|
|
path: accept the name length as a parameter
We may take in names from the middle of a string so we want the caller to let us
know how long the path component is that we should be checking.
|
|
|
a145f2b6
|
2018-05-22T14:16:45
|
|
checkout: add a failing test for refusing a symlinked .gitmodules
We want to reject these as they cause compatibility issues and can lead to git
writing to files outside of the repository.
|
|
|
177dcfc7
|
2018-05-18T15:16:53
|
|
path: hide the dotgit file functions
These can't go into the public API yet as we don't want to introduce API or ABI
changes in a security release.
|
|
|
9de97ae7
|
2018-05-16T15:42:08
|
|
path: add a function to detect an .gitmodules file
Given a path component it knows what to pass to the filesystem-specific
functions so we're protected even from trees which try to use the 8.3 naming
rules to get around us matching on the filename exactly.
The logic and test strings come from the equivalent git change.
|
|
|
397abe98
|
2018-05-14T16:03:15
|
|
submodule: also validate Windows-separated paths for validity
Otherwise we would also admit `..\..\foo\bar` as a valid path and fail to
protect Windows users.
Ideally we would check for both separators without the need for the copied
string, but this'll get us over the RCE.
|
|
|
6b15ceac
|
2018-04-30T13:47:15
|
|
submodule: ignore submodules which include path traversal in their name
If the we decide that the "name" of the submodule (i.e. its path inside
`.git/modules/`) is trying to escape that directory or otherwise trick us, we
ignore the configuration for that submodule.
This leaves us with a half-configured submodule when looking it up by path, but
it's the same result as if the configuration really were missing.
The name check is potentially more strict than it needs to be, but it lets us
re-use the check we're doing for the checkout. The function that encapsulates
this logic is ready to be exported but we don't want to do that in a security
release so it remains internal for now.
|
|
|
f9cf9a04
|
2018-05-09T14:51:57
|
|
Merge pull request #4642 from pks-t/pks/cmake-resolve-pkgconfig
cmake: resolve libraries found by pkg-config
|
|
|
6c2939d6
|
2018-05-09T13:57:17
|
|
Merge pull request #4646 from pks-t/pks/gcc-8.1-warnings
Fix GCC 8.1 warnings
|
|
|
8ab470f5
|
2018-04-27T15:31:43
|
|
cmake: remove now-useless LIBGIT2_LIBDIRS handling
With the recent change of always resolving pkg-config libraries to their
full path, we do not have to manage the LIBGIT2_LIBDIRS variable
anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp,
which is a CMake-style library target and can thus be resolved by CMake
automatically.
Remove the variable to simplify our build system a bit.
|
|
|
a82082d0
|
2018-04-20T08:38:50
|
|
worktree: a worktree can be made from a bare repository
|
|
|
bb468ada
|
2018-05-07T13:44:15
|
|
Merge pull request #4542 from stanhu/sh-sanitize-utf8-hunk-header
Sanitize the hunk header to ensure it contains UTF-8 valid data
|
|
9d83a2b0
|
2018-02-22T22:55:50
|
|
Sanitize the hunk header to ensure it contains UTF-8 valid data
The diff driver truncates the hunk header text to 80 bytes, which can truncate
4-byte Unicode characters and introduce garbage characters in the diff
output. This change sanitizes the hunk header before it is displayed.
This mirrors the test in git: https://github.com/git/git/blob/master/t/t4025-hunk-header.sh
Closes https://github.com/libgit2/rugged/issues/716
|
|
|
1bf57b5a
|
2018-05-04T15:27:11
|
|
tests: iterator::workdir: fix GCC warning
Since GCC 8.1, the compiler performs some bounds checking when
copying static data into arrays with a known size. In one test,
we print a format string of "%s/sub%02d" into a buffer of 64
bytes. The input buffer for the first "%s" is bounded to at most
63 characters, plus four bytes for the static string "/sub" plus
two more bytes for "%02d". Thus, our target buffer needs to be at
least 70 bytes in size, including the NUL byte. There seems to be
a bug in the analysis, though, because GCC will not account for
the limiting "%02" prefix, treating it as requiring the same
count of bytes as a "%d".
Thus, we end up at 79 bytes that are required to fix the
warning. To make it look nicer and less special, we just round
the buffer size up to 80 bytes.
|
|
|
0750d0cc
|
2018-05-04T15:25:22
|
|
tests: refs::normalize: simplify code to avoid GCC warning
Since version 8.1, GCC will do some automatic bounds checking
when printing static content into a buffer with known size. The
bounds checking doesn't yet work quite right in all scenarios and
may thus lead to false positives. Fix one of these false
positives in refs::normalize by simplifying the code.
|
|
|
7553763a
|
2018-04-30T13:03:44
|
|
submodule: add a failing test for a submodule escaping .git/modules
We should pretend such submdules do not exist as it can lead to RCE.
|
|
|
b33b6d33
|
2018-04-30T09:27:47
|
|
Merge pull request #4640 from mkeeler/worktree-convenience2
worktree: add functions to get name and path
|
|
|
5ace1494
|
2018-04-26T11:45:38
|
|
Merge pull request #4633 from csware/worktree-delereref
Fix deletion of unrelated branch on worktree
|
|
3da1ad20
|
2018-04-24T17:09:34
|
|
worktree: add functions to get name and path
|
|
|
45a3b9cd
|
2018-04-24T17:12:49
|
|
tests: fix issue with /tmp paths on macOS[1]
|
|
|
86353a72
|
2018-04-22T14:57:02
|
|
Merge pull request #4173 from tiennou/mbedtls
mbedTLS support
|
|
|
5d346c11
|
2018-04-22T14:51:00
|
|
Merge pull request #4525 from pks-t/pks/config-iterate-in-order
Configuration entry iteration in order
|
|
|
0ad2372b
|
2018-04-20T21:25:01
|
|
Merge pull request #4636 from tiennou/fix/leaks
Fix leaks in master
|
|
|
8d138f89
|
2018-04-20T20:28:48
|
|
Merge pull request #4577 from csware/reflog-worktree-head
worktree: Read worktree specific reflog for HEAD
|
|
|
25100d6d
|
2018-04-19T19:17:07
|
|
tests: free the worktree in add_with_explicit_branch
Valgrind log:
==2711== 305 (48 direct, 257 indirect) bytes in 1 blocks are definitely lost in loss record 576 of 624
==2711== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2711== by 0x5E079E: git__calloc (util.h:99)
==2711== by 0x5E0D21: open_worktree_dir (worktree.c:134)
==2711== by 0x5E0F23: git_worktree_lookup (worktree.c:176)
==2711== by 0x5E1972: git_worktree_add (worktree.c:388)
==2711== by 0x551F23: test_worktree_worktree__add_with_explicit_branch (worktree.c:292)
==2711== by 0x45853E: clar_run_test (clar.c:222)
==2711== by 0x4587E1: clar_run_suite (clar.c:286)
==2711== by 0x458B04: clar_parse_args (clar.c:362)
==2711== by 0x458CAB: clar_test_run (clar.c:428)
==2711== by 0x45665C: main (main.c:24)
|
|
|
fd7b5bc3
|
2018-04-20T12:54:41
|
|
Fix deletion of unrelated branch on worktree
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
fac7eac4
|
2018-04-19T15:21:52
|
|
fixed stack smashing due to wrong size of struct stat on the stack
on 32-bit systems with 64-bit file descriptor offsets enabled
(added -D_FILE_OFFSET_BITS=64 when compiling the test suite)
|
|
|
8529ac9b
|
2018-04-17T23:38:46
|
|
Merge pull request #4524 from pks-t/pks/worktree-refs
worktree: add ability to create worktree with pre-existing branch
|