|
305e801a
|
2018-10-21T09:52:32
|
|
util: allow callers to reset custom allocators
Provide a utility to reset custom allocators back to their default.
This is particularly useful for testing.
|
|
|
7c791f3d
|
2018-10-20T20:25:51
|
|
Merge pull request #4852 from libgit2/ethomson/unc_paths
Win32 path canonicalization refactoring
|
|
|
6cc14ae3
|
2018-10-20T20:22:04
|
|
Merge pull request #4840 from libgit2/cmn/validity-tree-from-unowned-index
Check object existence when creating a tree from an index
|
|
|
a2f9f94b
|
2018-10-20T20:18:04
|
|
Merge branch 'issue-4203'
|
|
|
32b81661
|
2018-10-20T20:16:32
|
|
merge: don't leak the index during reloads
|
|
0a4284b1
|
2018-10-19T14:54:13
|
|
Merge pull request #4819 from libgit2/cmn/config-nonewline
Configuration variables can appear on the same line as the section header
|
|
|
a34f5b0d
|
2018-10-18T08:57:27
|
|
win32: refactor `git_win32_path_remove_namespace`
Update `git_win32_path_remove_namespace` to disambiguate the prefix
being removed versus the prefix being added. Now we remove the
"namespace", and (may) add a "prefix" in its place. Eg, we remove the
`\\?\` namespace. We remove the `\\?\UNC\` namespace, and replace it
with the `\\` prefix. This aids readability somewhat.
Additionally, use pointer arithmetic instead of offsets, which seems to
also help readability.
|
|
|
b2e85f98
|
2018-10-17T08:48:43
|
|
win32: rename `git_win32__canonicalize_path`
The internal API `git_win32__canonicalize_path` is far, far too easily
confused with the internal API `git_win32_path_canonicalize`. The
former removes the namespace prefix from a path (eg, given
`\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given
`\\?\UNC\server\share`, it returns `\\server\share`). As such, rename
it to `git_win32_path_remove_namespace`.
`git_win32_path_canonicalize` remains unchanged.
|
|
|
f010b66b
|
2018-10-17T14:33:47
|
|
Merge pull request #4849 from libgit2/cmn/expose-gitfile-check
path: export the dotgit-checking functions
|
|
7615794c
|
2018-10-15T18:08:13
|
|
Merge pull request #4845 from pks-t/pks/object-fuzzer
Object parsing fuzzer
|
|
9b6e4081
|
2018-10-15T17:08:38
|
|
Merge commit 'afd10f0' (Follow 308 redirects)
|
|
|
05e54e00
|
2018-10-15T13:54:17
|
|
path: export the dotgit-checking functions
These checks are preformed by libgit2 on checkout, but they're also useful for
performing checks in applications which do not involve checkout.
Expose them under `sys/` as it's still fairly in the weeds even for this
library.
|
|
|
1d718fa5
|
2018-09-28T11:55:34
|
|
config: variables might appear on the same line as a section header
While rare and a machine would typically not generate such a configuration file,
it is nevertheless valid to write
[foo "bar"] baz = true
and we need to deal with that instead of assuming everything is on its own line.
|
|
afd10f0b
|
2018-10-13T09:31:20
|
|
Follow 308 redirects (as used by GitLab)
|
|
|
814e7acb
|
2018-10-12T12:38:06
|
|
Merge pull request #4842 from nelhage/fuzz-config-memory
config: Port config_file_fuzzer to the new in-memory backend.
|
|
463c21e2
|
2018-10-11T13:27:06
|
|
Apply code review feedback
|
|
|
6562cdda
|
2018-10-11T12:43:08
|
|
object: properly propagate errors on parsing failures
When failing to parse a raw object fromits data, we free the
partially parsed object but then fail to propagate the error to the
caller. This may lead callers to operate on objects with invalid memory,
which will sooner or later cause the program to segfault.
Fix the issue by passing up the error code returned by `parse_raw`.
|
|
|
2d449a11
|
2018-10-09T02:42:14
|
|
config: Refactor `git_config_backend_from_string` to take a length
|
|
|
fd490d3e
|
2018-10-08T13:15:31
|
|
tree: unify the entry validity checks
We have two similar functions, `git_treebuilder_insert` and `append_entry` which
are used in different codepaths as part of creating a new tree. The former
learnt to check for object existence under strict object creation, but the
latter did not.
This allowed the creation of a tree from an unowned index to bypass some of the
checks and create a tree pointing to a nonexistent object.
Extract a single function which performs these checks and call it from both
codepaths. In `append_entry` we still do not validate when asked not to, as this
is data which is already in the tree and we want to allow users to deal with
repositories which already have some invalid data.
|
|
|
0cd976c8
|
2018-10-07T12:00:06
|
|
Merge pull request #4830 from pks-t/pks/diff-stats-rename-common
diff_stats: use git's formatting of renames with common directories
|
|
475db39b
|
2018-10-06T12:58:06
|
|
ignore unsupported http authentication schemes
auth_context_match returns 0 instead of -1 for unknown schemes to
not fail in situations where some authentication schemes are supported
and others are not.
apply_credentials is adjusted to handle auth_context_match returning
0 without producing authentication context.
|
|
|
a8d447f6
|
2018-10-05T20:13:34
|
|
Merge pull request #4837 from pks-t/cmn/reject-option-submodule-url-path
submodule: ignore path and url attributes if they look like options
|
|
|
ce8803a2
|
2018-10-05T20:03:38
|
|
Merge pull request #4836 from pks-t/pks/smart-packets
Smart packet security fixes
|
|
|
c8ca3cae
|
2018-10-05T11:47:39
|
|
submodule: ignore path and url attributes if they look like options
These can be used to inject options in an implementation which performs a
recursive clone by executing an external command via crafted url and path
attributes such that it triggers a local executable to be run.
The library is not vulnerable as we do not rely on external executables but a
user of the library might be relying on that so we add this protection.
This matches this aspect of git's fix for CVE-2018-17456.
|
|
|
d06d4220
|
2018-10-05T10:56:02
|
|
config_file: properly ignore includes without "path" value
In case a configuration includes a key "include.path=" without any
value, the generated configuration entry will have its value set to
`NULL`. This is unexpected by the logic handling includes, and as soon
as we try to calculate the included path we will unconditionally
dereference that `NULL` pointer and thus segfault.
Fix the issue by returning early in both `parse_include` and
`parse_conditional_include` in case where the `file` argument is `NULL`.
Add a test to avoid future regression.
The issue has been found by the oss-fuzz project, issue 10810.
|
|
|
e5090ee3
|
2018-10-04T11:19:28
|
|
diff_stats: use git's formatting of renames with common directories
In cases where a file gets renamed such that the directories containing
it previous and after the rename have a common prefix, then git will
avoid printing this prefix twice and instead format the rename as
"prefix/{old => new}". We currently didn't do anything like that, but
simply printed "prefix/old -> prefix/new".
Adjust our behaviour to instead match upstream. Adjust the test for this
behaviour to expect the new format.
|
|
|
1bc5b05c
|
2018-10-03T16:17:21
|
|
smart_pkt: do not accept callers passing in no line length
Right now, we simply ignore the `linelen` parameter of
`git_pkt_parse_line` in case the caller passed in zero. But in fact, we
never want to assume anything about the provided buffer length and
always want the caller to pass in the available number of bytes.
And in fact, checking all the callers, one can see that the funciton is
never being called in case where the buffer length is zero, and thus we
are safe to remove this check.
|
|
|
c05790a8
|
2018-08-09T11:16:15
|
|
smart_pkt: return parsed length via out-parameter
The `parse_len` function currently directly returns the parsed length of
a packet line or an error code in case there was an error. Instead,
convert this to our usual style of using the return value as error code
only and returning the actual value via an out-parameter. Thus, we can
now convert the output parameter to an unsigned type, as the size of a
packet cannot ever be negative.
While at it, we also move the check whether the input buffer is long
enough into `parse_len` itself. We don't really want to pass around
potentially non-NUL-terminated buffers to functions without also passing
along the length, as this is dangerous in the unlikely case where other
callers for that function get added. Note that we need to make sure
though to not mess with `GIT_EBUFS` error codes, as these indicate not
an error to the caller but that he needs to fetch more data.
|
|
|
0b3dfbf4
|
2018-08-09T11:13:59
|
|
smart_pkt: reorder and rename parameters of `git_pkt_parse_line`
The parameters of the `git_pkt_parse_line` function are quite confusing.
First, there is no real indicator what the `out` parameter is actually
all about, and it's not really clear what the `bufflen` parameter refers
to. Reorder and rename the parameters to make this more obvious.
|
|
|
5fabaca8
|
2018-08-09T11:04:42
|
|
smart_pkt: fix buffer overflow when parsing "unpack" packets
When checking whether an "unpack" packet returned the "ok" status or
not, we use a call to `git__prefixcmp`. In case where the passed line
isn't properly NUL terminated, though, this may overrun the line buffer.
Fix this by using `git__prefixncmp` instead.
|
|
|
b5ba7af2
|
2018-08-09T11:03:37
|
|
smart_pkt: fix "ng" parser accepting non-space character
When parsing "ng" packets, we blindly assume that the character
immediately following the "ng" prefix is a space and skip it. As the
calling function doesn't make sure that this is the case, we can thus
end up blindly accepting an invalid packet line.
Fix the issue by using `git__prefixncmp`, checking whether the line
starts with "ng ".
|
|
|
a9f1ca09
|
2018-08-09T11:01:00
|
|
smart_pkt: fix buffer overflow when parsing "ok" packets
There are two different buffer overflows present when parsing "ok"
packets. First, we never verify whether the line already ends after
"ok", but directly go ahead and also try to skip the expected space
after "ok". Second, we then go ahead and use `strchr` to scan for the
terminating newline character. But in case where the line isn't
terminated correctly, this can overflow the line buffer.
Fix the issues by using `git__prefixncmp` to check for the "ok " prefix
and only checking for a trailing '\n' instead of using `memchr`. This
also fixes the issue of us always requiring a trailing '\n'.
Reported by oss-fuzz, issue 9749:
Crash Type: Heap-buffer-overflow READ {*}
Crash Address: 0x6310000389c0
Crash State:
ok_pkt
git_pkt_parse_line
git_smart__store_refs
Sanitizer: address (ASAN)
|
|
|
bc349045
|
2018-08-09T10:38:10
|
|
smart_pkt: fix buffer overflow when parsing "ACK" packets
We are being quite lenient when parsing "ACK" packets. First, we didn't
correctly verify that we're not overrunning the provided buffer length,
which we fix here by using `git__prefixncmp` instead of
`git__prefixcmp`. Second, we do not verify that the actual contents make
any sense at all, as we simply ignore errors when parsing the ACKs OID
and any unknown status strings. This may result in a parsed packet
structure with invalid contents, which is being silently passed to the
caller. This is being fixed by performing proper input validation and
checking of return codes.
|
|
|
5edcf5d1
|
2018-08-09T10:57:06
|
|
smart_pkt: adjust style of "ref" packet parsing function
While the function parsing ref packets doesn't have any immediately
obvious buffer overflows, it's style is different to all the other
parsing functions. Instead of checking buffer length while we go, it
does a check up-front. This causes the code to seem a lot more magical
than it really is due to some magic constants. Refactor the function to
instead make use of the style of other packet parser and verify buffer
lengths as we go.
|
|
|
786426ea
|
2018-08-09T10:46:58
|
|
smart_pkt: check whether error packets are prefixed with "ERR "
In the `git_pkt_parse_line` function, we determine what kind of packet
a given packet line contains by simply checking for the prefix of that
line. Except for "ERR" packets, we always only check for the immediate
identifier without the trailing space (e.g. we check for an "ACK"
prefix, not for "ACK "). But for "ERR" packets, we do in fact include
the trailing space in our check. This is not really much of a problem at
all, but it is inconsistent with all the other packet types and thus
causes confusion when the `err_pkt` function just immediately skips the
space without checking whether it overflows the line buffer.
Adjust the check in `git_pkt_parse_line` to not include the trailing
space and instead move it into `err_pkt` for consistency.
|
|
|
40fd84cc
|
2018-08-09T10:46:26
|
|
smart_pkt: explicitly avoid integer overflows when parsing packets
When parsing data, progress or error packets, we need to copy the
contents of the rest of the current packet line into the flex-array of
the parsed packet. To keep track of this array's length, we then assign
the remaining length of the packet line to the structure. We do have a
mismatch of types here, as the structure's `len` field is a signed
integer, while the length that we are assigning has type `size_t`.
On nearly all platforms, this shouldn't pose any problems at all. The
line length can at most be 16^4, as the line's length is being encoded
by exactly four hex digits. But on a platforms with 16 bit integers,
this assignment could cause an overflow. While such platforms will
probably only exist in the embedded ecosystem, we still want to avoid
this potential overflow. Thus, we now simply change the structure's
`len` member to be of type `size_t` to avoid any integer promotion.
|
|
|
4a5804c9
|
2018-08-09T10:36:44
|
|
smart_pkt: honor line length when determining packet type
When we parse the packet type of an incoming packet line, we do not
verify that we don't overflow the provided line buffer. Fix this by
using `git__prefixncmp` instead and passing in `len`. As we have
previously already verified that `len <= linelen`, we thus won't ever
overflow the provided buffer length.
|
|
|
b36cc7a4
|
2018-09-27T11:18:00
|
|
fix check if blob is uninteresting when inserting tree to packbuilder
Blobs that have been marked as uninteresting should not be inserted into packbuilder
when inserting a tree. The check as to whether a blob was uninteresting looked at
the status for the tree itself instead of the blob.
This could cause significantly larger packfiles.
|
|
8ab11dd5
|
2018-09-30T16:40:22
|
|
Fix issue with path canonicalization for Win32 paths
|
|
|
0530d7d9
|
2018-09-28T18:04:23
|
|
Merge pull request #4767 from pks-t/pks/config-mem
In-memory configuration
|
|
|
2be39cef
|
2018-08-10T19:38:57
|
|
config: introduce new read-only in-memory backend
Now that we have abstracted away how to store and retrieve config
entries, it became trivial to implement a new in-memory backend by
making use of this. And thus we do so.
This commit implements a new read-only in-memory backend that can parse
a chunk of memory into a `git_config_backend` structure.
|
|
|
b78f4ab0
|
2018-08-16T12:22:03
|
|
config_entries: refactor entries iterator memory ownership
Right now, the config file code requires us to pass in its backend to
the config entry iterator. This is required with the current code, as
the config file backend will first create a read-only snapshot which is
then passed to the iterator just for that purpose. So after the iterator
is getting free'd, the code needs to make sure that the snapshot gets
free'd, as well.
By now, though, we can easily refactor the code to be more efficient and
remove the reverse dependency from iterator to backend. Instead of
creating a read-only snapshot (which also requires us to re-parse the
complete configuration file), we can simply duplicate the config entries
and pass those to the iterator. Like that, the iterator only needs to
make sure to free the duplicated config entries, which is trivial to do
and clears up memory ownership by a lot.
|
|
|
d49b1365
|
2018-08-10T19:01:37
|
|
config_entries: internalize structure declarations
Access to the config entries is now completely done via the modules
function interface and no caller messes with the struct's internals. We
can thus completely move the structure declarations into the
implementation file so that nobody even has a chance to mess with the
members.
|
|
|
123e5963
|
2018-08-10T18:59:59
|
|
config_entries: abstract away reference counting
Instead of directly calling `git_atomic_inc` in users of the config
entries store, provide a `git_config_entries_incref` function to further
decouple the interfaces. Convert the refcount to a `git_refcount`
structure while at it.
|
|
|
5a7e0b3c
|
2018-08-10T18:49:38
|
|
config_entries: abstract away iteration over entries
The nice thing about our `git_config_iterator` interfaces is that nobody
needs to know anything about the implementation details. All that is
required is to obtain the iterator via any backend and then use it by
executing generic functions. We can thus completely internalize all the
implementation details of how to iterate over entries into the config
entries store and simply create such an iterator in our config file
backend when we want to iterate its entries. This further decouples the
config file backend from the config entries store.
|
|
|
60ebc137
|
2018-08-10T14:53:09
|
|
config_entries: abstract away retrieval of config entries
The code accessing config entries in the `git_config_entries` structure
is still much too intimate with implementation details, directly
accessing the maps and handling indices. Provide two new functions to
get config entries from the internal map structure to decouple the
interfaces and use them in the config file code.
The function `git_config_entries_get` will simply look up the entry by
name and, in the case of a multi-value, return the last occurrence of
that entry. The second function, `git_config_entries_get_unique`, will
only return an entry if it is unique and not included via another
configuration file. This one is required to properly implement write
operations for single entries, as we refuse to write to or delete a
single entry if it is not clear which one was meant.
|
|
|
fb8a87da
|
2018-08-10T14:50:15
|
|
config_entries: rename functions and structure
The previous commit simply moved all code that is required to handle
config entries to a new module without yet adjusting any of the function
and structure names to help readability. We now rename things
accordingly to have a common "git_config_entries" entries instead of the
old "diskfile_entries" one.
|
|
|
04f57d51
|
2018-08-10T13:33:02
|
|
config_entries: pull out implementation of entry store
The configuration entry store that is used for configuration files needs
to keep track of all entries in two different structures:
- a singly linked list is being used to be able to iterate through
configuration files in the order they have been found
- a string map is being used to efficiently look up configuration
entries by their key
This store is thus something that may be used by other, future backends
as well to abstract away implementation details and iteration over the
entries.
Pull out the necessary functions from "config_file.c" and moves them
into their own "config_entries.c" module. For now, this is simply moving
over code without any renames and/or refactorings to help reviewing.
|
|
|
d75bbea1
|
2018-08-10T14:35:23
|
|
config_file: remove unnecessary snapshot indirection
The implementation for config file snapshots has an unnecessary
redirection from `config_snapshot` to `git_config_file__snapshot`.
Inline the call to `git_config_file__snapshot` and remove it.
|
|
|
b944e137
|
2018-08-10T13:03:33
|
|
config: rename "config_file.h" to "config_backend.h"
The header "config_file.h" has a list of inline-functions to access the
contents of a config backend without directly messing with the struct's
function pointers. While all these functions are called
"git_config_file_*", they are in fact completely backend-agnostic and
don't care whether it is a file or not. Rename all the function to
instead be backend-agnostic versions called "git_config_backend_*" and
rename the header to match.
|
|
|
1aeff5d7
|
2018-08-10T12:52:18
|
|
config: move function normalizing section names into "config.c"
The function `git_config_file_normalize_section` is never being used in
any file different than "config.c", but it is implemented in
"config_file.c". Move it over and make the symbol static.
|
|
|
a5562692
|
2018-08-10T12:49:50
|
|
config: make names backend-agnostic
As a last step to make variables and structures more backend agnostic
for our `git_config` structure, rename local variables to not be called
`file` anymore.
|
|
|
ba1cd495
|
2018-09-28T11:10:49
|
|
Merge pull request #4784 from tiennou/fix/warnings
Some warnings
|
|
|
367f6243
|
2018-09-28T11:04:06
|
|
Merge pull request #4803 from tiennou/fix/4802
index: release the snapshot instead of freeing the index
|
|
e0afd1c2
|
2018-09-26T21:17:39
|
|
vector: do not realloc 0-size vectors
|
|
|
fa48d2ea
|
2018-09-26T19:15:35
|
|
vector: do not malloc 0-length vectors on dup
|
|
|
be4717d2
|
2018-09-18T12:12:06
|
|
path: fix "comparison always true" warning
|
|
|
21496c30
|
2018-03-30T00:20:23
|
|
stransport: fix a warning on iOS
"warning: values of type 'OSStatus' should not be used as format arguments; add an explicit cast to 'int' instead [-Wformat]"
|
|
|
a54043b7
|
2018-09-21T15:32:18
|
|
Merge pull request #4794 from marcin-krystianc/mkrystianc/prune_perf
git_remote_prune to be O(n * logn)
|
|
|
83733aeb
|
2018-08-10T12:43:21
|
|
config: rename `file_internal` and its `file` member
Same as with the previous commit, the `file_internal` struct is used to
keep track of all the backends that are added to a `git_config` struct.
Rename it to `backend_internal` and rename its `file` member to
`backend` to make the implementation more backend-agnostic.
|
|
|
633cf40c
|
2018-08-10T12:39:17
|
|
config: rename `files` vector to `backends`
Originally, the `git_config` struct is a collection of all the parsed
configuration files from different scopes (system-wide config,
user-specific config as well as the repo-specific config files).
Historically, we didn't and don't yet have any other configuration
backends than the one for files, which is why the field holding the
config backends is called `files`. But in fact, nothing dictates that
the vector of backends actually holds file backends only, as they are
generic and custom backends can be implemented by users.
Rename the member to be called `backends` to clarify that there is
nothing specific to files here.
|
|
|
b9affa32
|
2018-08-10T19:23:00
|
|
config_parse: avoid unused static declared values
The variables `git_config_escaped` and `git_config_escapes` are both
defined as static const character pointers in "config_parse.h". In case
where "config_parse.h" is included but those two variables are not being
used, the compiler will thus complain about defined but unused
variables. Fix this by declaring them as external and moving the actual
initialization to the C file.
Note that it is not possible to simply make this a #define, as we are
indexing into those arrays.
|
|
|
0b9c68b1
|
2018-08-16T14:10:58
|
|
submodule: fix submodule names depending on config-owned memory
When populating the list of submodule names, we use the submodule
configuration entry's name as the key in the map of submodule names.
This creates a hidden dependency on the liveliness of the configuration
that was used to parse the submodule, which is fragile and unexpected.
Fix the issue by duplicating the string before writing it into the
submodule name map.
|
|
|
e181a649
|
2018-09-18T03:03:03
|
|
Merge pull request #4809 from libgit2/cmn/revwalk-sign-regression
Fix revwalk limiting regression
|
|
|
12a1790d
|
2018-09-17T14:49:46
|
|
revwalk: only check the first commit in the list for an earlier timestamp
This is not a big deal, but it does make us match git more closely by checking
only the first. The lists are sorted already, so there should be no functional
difference other than removing a possible check from every iteration in the
loop.
|
|
|
46f35127
|
2018-09-17T14:39:58
|
|
revwalk: use the max value for a signed integer
When porting, we overlooked that the difference between git's and our's time
representation and copied their way of getting the max value.
Unfortunately git was using unsigned integers, so `~0ll` does correspond to
their max value, whereas for us it corresponds to `-1`. This means that we
always consider the last date to be smaller than the current commit's and always
think commits are interesting.
Change the initial value to the macro that gives us the maximum value on each
platform so we can accurately consider commits interesting or not.
|
|
|
44291868
|
2018-09-12T10:53:03
|
|
path validation: `char` is not signed by default.
ARM treats its `char` type as `unsigned type` by default; as a result,
testing a `char` value as being `< 0` is always false. This is a
warning on ARM, which is promoted to an error given our use of
`-Werror`.
Per ISO 9899:199, section "6.2.5 Types":
> The three types char, signed char, and unsigned char are collectively
> called the character types. The implementation shall define char to
> have the same range, representation, and behavior as either signed
> char or unsigned char.
>
...
> Irrespective of the choice made, char is a separate type from the other
> two and is not compatible with either.
|
|
|
c70713d6
|
2018-09-11T15:53:35
|
|
index: release the snapshot instead of freeing the index
Previously we would assert in index_free because the reader incrementation
would not be balanced. Release the snapshot normally, so the variable gets
decremented before the index is freed.
|
|
|
55d354d8
|
2018-09-07T13:20:33
|
|
Merge pull request #4785 from tiennou/fix/cleanup-remote
remote: store the connection data in a private struct
|
|
|
1c176883
|
2018-09-07T10:36:15
|
|
remote: store the connection data in a private struct
This makes it easier to pass connection-related options around (proxy &
custom headers for now).
This fixes a bug in git_push_finish, which didn't reuse the provided
proxy if the connection closed between the call to `git_remote_push` and
the finish step.
|
|
|
f2694635
|
2018-09-06T14:17:54
|
|
config_file: fix quadratic behaviour when adding config multivars
In case where we add multiple configuration entries with the same key to
a diskfile backend, we always need to iterate the list of this key to
find the last entry due to the list being a singly-linked list. This
is obviously quadratic behaviour, and this has sure enough been found by
oss-fuzz by generating a configuration file with 50k lines, where most
of them have the same key. While the issue will not arise with "sane"
configuration files, an adversary may trigger it by providing a crafted
".gitmodules" file, which is delivered as part of the repo and also
parsed by the configuration parser.
The fix is trivial: store a pointer to the last entry of the list in its
head. As there are only two locations now where we append to this data
structure, mainting this pointer is trivial, too. We can also optimize
retrieval of a single value via `config_get`, where we previously had to
chase the `next` pointer to find the last entry that was added.
Using our configuration file fozzur with a corpus that has a single file
with 50000 "-=" lines previously took around 21s. With this optimization
the same file scans in about 0.053s, which is a nearly 400-fold
improvement. But in most cases with a "normal" amount of same-named keys
it's not going to matter anyway.
|
|
|
695067f7
|
2018-09-06T11:54:01
|
|
Merge pull request #4792 from nelhage/multiline-leak
config: Fix a leak parsing multi-line config entries
|
|
d22cd1f4
|
2018-09-05T11:49:13
|
|
Prevent heap-buffer-overflow
When running repack while doing repo writes, `packfile_load__cb()` can see some temporary files in the directory that are bigger than the usual, and makes `memcmp` overflow on the `p->pack_name` string. ASAN detected this. This just uses `strncmp`, that should not have any performance impact and is safe for comparing strings of different sizes.
```
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61200001a3f3 at pc 0x7f4a9e1976ec bp 0x7ffc1f80e100 sp 0x7ffc1f80d8b0
READ of size 89 at 0x61200001a3f3 thread T0
SCARINESS: 26 (multi-byte-read-heap-buffer-overflow)
#0 0x7f4a9e1976eb in __interceptor_memcmp.part.78 (/build/cfgr-admin#link-tree/libtools_build_sanitizers_asan-ubsan-py.so+0xcf6eb)
#1 0x7f4a518c5431 in packfile_load__cb /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb_pack.c:213
#2 0x7f4a518d9582 in git_path_direach /build/libgit2/0.27.0/src/libgit2-0.27.0/src/path.c:1134
#3 0x7f4a518c58ad in pack_backend__refresh /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb_pack.c:347
#4 0x7f4a518c1b12 in git_odb_refresh /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:1511
#5 0x7f4a518bff5f in git_odb__freshen /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:752
#6 0x7f4a518c17d4 in git_odb_stream_finalize_write /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:1415
#7 0x7f4a51b9d015 in Repository_write /build/pygit2/0.27.0/src/pygit2-0.27.0/src/repository.c:509
```
|
|
|
bc63e1ef
|
2018-09-03T10:49:46
|
|
config_parse: refactor error handling when parsing multiline variables
The current error handling for the multiline variable parser is a bit
fragile, as each error condition has its own code to clear memory.
Instead, unify error handling as far as possible to avoid this
repetitive code. While at it, make use of `GITERR_CHECK_ALLOC` to
correctly handle OOM situations and verify that the buffer we print into
does not run out of memory either.
|
|
bfec6526
|
2018-09-02T11:38:43
|
|
git_remote_prune to be O(n * logn)
|
|
|
38b85255
|
2018-09-01T03:50:26
|
|
config: Fix a leak parsing multi-line config entries
|
|
|
2054fe50
|
2018-08-30T12:41:15
|
|
Merge pull request #4781 from nelhage/multiline-loop
config: convert unbounded recursion into a loop
|
|
|
df2f276e
|
2018-08-26T13:22:55
|
|
Merge pull request #4765 from tiennou/fix/macos-qsort_r
util: make the qsort_r check work on macOS
|
|
|
85eb2cb6
|
2018-08-26T11:33:42
|
|
Merge pull request #4727 from libgit2/cmn/null-oid-existing-tree
tree: accept null ids in existing trees when updating
|
|
|
50186ce8
|
2018-08-26T11:26:45
|
|
Merge pull request #4374 from pks-t/pks/pack-file-verify
Pack file verification
|
|
|
a03113e8
|
2018-08-25T17:04:39
|
|
config: convert unbounded recursion into a loop
|
|
|
1a9cc182
|
2018-08-17T15:56:30
|
|
util: make the qsort_r check work on macOS
This performs a compile-check by using CMake support, to differentiate the GNU
version from the BSD version of qsort_r.
Module taken from 4f252abea5f1d17c60f6ff115c9c44cc0b6f1df6, which I've checked
against CMake 2.8.11.
|
|
|
9a193102
|
2018-08-24T11:01:39
|
|
Merge pull request #4774 from tiennou/fix/clang-analyzer
Coverity flavored clang analyzer fixes
|
|
|
503af775
|
2018-08-24T10:08:09
|
|
Merge pull request #4769 from tiennou/fix/worktree-unlock
worktree: unlock should return 1 when the worktree isn't locked
|
|
|
296cb5e6
|
2018-08-24T09:07:01
|
|
Merge pull request #4763 from cschlack/fix_ng_packets
Fix 'invalid packet line' for ng packets containing errors
|
|
|
1c949ce1
|
2018-08-21T02:11:32
|
|
transport/http: do not return success if we failed to get a scheme
Otherwise we return a NULL context, which will get dereferenced in
apply_credentials.
|
|
|
22d013b6
|
2018-08-21T01:55:56
|
|
remote: set the error before cleanup
Otherwise we'll return stack data to the caller.
|
|
|
ad95873b
|
2018-08-21T01:41:05
|
|
mailmap: Undefined or garbage value returned to caller
In case there was nothing to parse in the buf, we'd return uninitialized
stack data.
|
|
|
aa8cb586
|
2018-08-21T01:12:11
|
|
revwalk: The left operand of '<' is a garbage value
At line 594, we do this :
if (error < 0)
return error;
but if nothing was pushed in a GIT_SORT_TIME revwalk, we'd return
uninitialized stack data.
|
|
50dd7fea
|
2018-08-11T13:06:14
|
|
Fix 'invalid packet line' for ng packets containing errors
|
|
|
59c2e70e
|
2018-08-17T00:51:51
|
|
worktree: unlock should return 1 when the worktree isn't locked
The documentation states that git_worktree_unlock returns 0 on success,
and 1 on success if the worktree wasn't locked. Turns out we were
returning 0 in any of those cases.
|
|
581d5492
|
2018-08-16T22:45:43
|
|
Fix leak in index.c
|
|
|
622e12c1
|
2018-08-16T10:35:31
|
|
Merge pull request #4749 from neithernut/fix-git__linenlen-ub
parse: Do not initialize the content in context to NULL
|
|
|
43e7bf78
|
2018-08-16T10:27:49
|
|
Merge pull request #4750 from nelhage/nelhage-config-no-section
config_file: Don't crash on options without a section
|
|
|
c65568d8
|
2018-08-09T12:48:26
|
|
diff: fix OOM on AIX when finding similar deltas in empty diff
The function `git_diff_find_similar` keeps a function of cache
similarity metrics signatures, whose size depends on the number of
deltas passed in via the `diff` parameter. In case where the diff is
empty and thus doesn't have any deltas at all, we may end up allocating
this cache via a call to `git__calloc(0, sizeof(void *))`. At least on
AIX, allocating 0 bytes will result in a `NULL` pointer being returned,
which causes us to erroneously return an OOM error.
Fix this situation by simply returning early in case where we are being
passed an empty diff, as we cannot find any similarities in that case
anyway.
|
|
|
b093bb56
|
2018-08-06T13:08:15
|
|
Merge pull request #4759 from pks-t/pks/ci-werror
ci: enable compilation with "-Werror"
|
|
|
9ada072e
|
2018-08-06T13:31:23
|
|
Merge pull request #4758 from pks-t/pks/smart-pkt-oob-read
smart_pkt: fix potential OOB-read when processing ng packet
|
|
|
0fcd0563
|
2018-08-06T12:00:21
|
|
odb: fix use of wrong printf formatters
The `git_odb_stream` members `declared_size` and `received_bytes` are
both of the type `git_off_t`, which we usually defined to be a 64 bit
signed integer. Thus, passing these members to "PRIdZ" formatters is not
correct, as they are not guaranteed to accept big enough numbers.
Instead, use the "PRId64" formatter, which is able to represent 64 bit
signed integers.
|
|
|
ec76a1aa
|
2018-08-05T14:37:08
|
|
Add a comment
|
|
|
019409be
|
2018-08-05T14:25:22
|
|
Don't error on missing section, just continue
|