| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Users may fork libgit2 and run libgit2's CI on that, which is
delightful! However, if they do, we'll fail the documentation publish
phase, which is correct (because we don't allow them to publish _their_
version of the docs) but regrettable (since it should not fail).
Only run the documentation publish phase when we merge branches into the
libgit2/libgit2 repo.
|
| |\
| |
| | |
global: convert to fiber-local storage to fix exit races
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On Windows platforms, we automatically clean up the thread-local storage
upon detaching a thread via `DllMain()`. The thing is that this happens
for every thread of applications that link against the libgit2 DLL, even
those that don't have anything to do with libgit2 itself. As a result,
we cannot assume that these unsuspecting threads make use of our
`git_libgit2_init()` and `git_libgit2_shutdow()` reference counting,
which may lead to racy situations:
Thread 1 Thread 2
git_libgit2_shutdown()
DllMain(DETACH_THREAD)
git__free_tls_data()
git_atomic_dec() == 0
git__free_tls_data()
TlsFree(_tls_index)
TlsGetValue(_tls_index)
Due to the second thread never having executed `git_libgit2_init()`, the
first thread will clean up TLS data and as a result also free the
`_tls_index` variable. When detaching the second thread, we
unconditionally access the now-free'd `_tls_index` variable, which is
obviously not going to work out well.
Fix the issue by converting the code to use fiber-local storage instead
of thread-local storage. While FLS will behave the exact same as TLS if
no fibers are in use, it does allow us to specify a destructor similar
to the one that is accepted by pthread_key_create(3P). Like this, we do
not have to manually free indices anymore, but will let the FLS handle
calling the destructor. This allows us to get rid of `DllMain()`
completely, as we only used it to keep track of when threads were
exiting and results in an overall simplification of TLS cleanup.
|
| |\ \
| | |
| | |
| | |
| | | |
kastiglione/dl/fix-copypaste-in-git_cherrypick_commit-docstring
Fix copy&paste in git_cherrypick_commit docstring
|
| | | | |
|
| |\ \ \
| |_|/
|/| | |
patch_parse: fix out-of-bounds reads caused by integer underflow
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The patch format for binary files is a simple Base85 encoding with a
length byte as prefix that encodes the current line's length. For each
line, we thus check whether the line's actual length matches its
expected length in order to not faultily apply a truncated patch. This
also acts as a check to verify that we're not reading outside of the
line's string:
if (encoded_len > ctx->parse_ctx.line_len - 1) {
error = git_parse_err(...);
goto done;
}
There is the possibility for an integer underflow, though. Given a line
with a single prefix byte, only, `line_len` will be zero when reaching
this check. As a result, subtracting one from that will result in an
integer underflow, causing us to assume that there's a wealth of bytes
available later on. Naturally, this may result in an out-of-bounds read.
Fix the issue by checking both `encoded_len` and `line_len` for a
non-zero value. The binary format doesn't make use of zero-length lines
anyway, so we need to know that there are both encoded bytes and
remaining characters available at all.
This patch also adds a test that works based on the last error message.
Checking error messages is usually too tightly coupled, but in fact
parsing the patch failed even before the change. Thus the only
possibility is to use e.g. Valgrind, but that'd result in us not
catching issues when run without Valgrind. As a result, using the error
message is considered a viable tradeoff as we know that we didn't start
decoding Base85 in the first place.
|
| |\ \ \
| | | |
| | | | |
tests: fix compiler warning if tracing is disabled
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If building libgit2's test suite with tracing disabled, then the
compiler will emit a warning due to the unused `message_prefix`
function. Fix the issue by wrapping the whole file into ifdef's for
`GIT_TRACE` and providing separate empty function implementations for
both `cl_global_trace_register` and `cl_global_trace_disable`.
|
| |\ \ \
| |/ /
|/| | |
tests: config: only test parsing huge file with GITTEST_INVASIVE_SPEED
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
The test in config::stress::huge_section_with_many_values takes quite a
long time to execute. Hide it behind the GITTEST_INVASIVE_SPEED
environment varibale to not needlessly blow up execution time of tests.
As this environment variable is being set by the continuous integration,
we will execute it regularly anyway.
|
| |\ \
| | |
| | | |
diff: complete support for git patchid
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Current implementation of patchid is not computing a correct patchid
when given a patch where, for example, a new file is added or removed.
Some more corner cases need to be handled to have same behavior as git
patch-id command.
Add some more tests to cover those corner cases.
Signed-off-by: Gregory Herrero <gregory.herrero@oracle.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When not shown binary data is added or removed in a patch, patch parser
is currently returning 'error -1 - corrupt git binary header at line 4'.
Fix it by correctly handling case where binary data is added/removed.
Signed-off-by: Gregory Herrero <gregory.herrero@oracle.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Git is generating patch-id using a stripped down version of a patch
where hunk header and index information are not present.
Signed-off-by: Gregory Herrero <gregory.herrero@oracle.com>
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
Add a new 'print_index' flag to let the caller decide whether or not
'index <oid>..<oid>' should be printed.
Since patch id needs not to have index when hashing a patch, it will be
useful soon.
Signed-off-by: Gregory Herrero <gregory.herrero@oracle.com>
|
| |\ \
| | |
| | | |
Memory optimizations for config entries
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Multivars are configuration entries that have many values for the same
name; we can thus micro-optimize this case by just retaining the name of
the first configuration entry and freeing all the others, letting them
point to the string of the first entry.
The attached test case is an extreme example that demonstrates this. It
contains a section name that is approximately 500kB in size with 20.000
entries "a=b". Without the optimization, this would require at least
20000*500kB bytes, which is around 10GB. With this patch, it only
requires 500kB+20000*1B=20500kB.
The obvious culprit here is the section header, which we repeatedly
include in each of the configuration entry's names. This makes it very
easier for an adversary to provide a small configuration file that
disproportionally blows up in memory during processing and is thus a
feasible way for a denial-of-service attack. Unfortunately, we cannot
fix the root cause by e.g. having a separate "section" field that may
easily be deduplicated due to the `git_config_entry` structure being
part of our public API. So this micro-optimization is the best we can do
for now.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Whenever adding a configuration entry to the config entries structure,
we allocate two list heads:
- The first list head is added to the global list of config entries
in order to be able to iterate over configuration entries in the
order they were originally added.
- The second list head is added to the map of entries in order to
efficiently look up an entry by its name. If no entry with the
same name exists in the map, then we add the new entry to the map
directly. Otherwise, we append the new entry's list head to the
pre-existing entry's list in order to keep track of multivars.
While the former usecase is perfectly sound, the second usecase can be
optimized. The only reason why we keep track of multivar entries in
another separate list is to be able to determine whether an entry is
unique or not by seeing whether its `next` pointer is set. So we keep
track of a complete list of multivar entries just to have a single bit
of information of whether it has other multivar entries with the same
entry name.
We can completely get rid of this secondary list by just adding a
`first` field to the list structure itself. When executing
`git_config_entries_append`, we will then simply check whether the
configuration map already has an entry with the same name -- if so, we
will set the `first` to zero to indicate that it is not the initial
entry anymore. Instead of a second list head in the map, we can thus now
directly store the list head of the first global list inside of the map
and just refer to that bit.
Note that the more obvious solution would be to store a `unique` field
instead of a `first` field. But as we will only ever inspect the `first`
field of the _last_ entry that has been moved into the map, these are
semantically equivalent in that case.
Having a `first` field also allows for a minor optimization: for
multivar values, we can free the `name` field of all entries that are
_not_ first and have them point to the name of the first entry instead.
|
| | | |
| | |
| | |
| | |
| | | |
Some functions which are only used in "config_entries.c" are not marked
as static, which is being fixed by this very commit.
|
| |\ \ \
| | | |
| | | | |
ssh: include sha256 host key hash when supported
|
| | | |/
| |/| |
|
| |\ \ \
| | | |
| | | | |
Various examples shape-ups
|
| | | | |
| | | |
| | | |
| | | | |
This allows the example to be used as a quick revwalk test harness.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
Improve trace support in tests
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Only show test trace execution when the CLAR_TRACE_TESTS environment
variable is set. This reduces the noise during tracing.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Tracing is meant to be extremely low-impact when not enabled. We
currently ship no tracing calls in libgit2, but if / when we do, the
tracing infrastructure is created to skip tracing as quickly as
possible. It should compile to a simple test when tracing is off.
Thus, there's on reason to not enable it by default.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Move `git_off_t` to `git_object_size_t`
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Prefer `off64_t` internally.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Use int64_t internally for type visibility.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Prefer `off64_t` to `git_off_t` internally for visibility.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Prefer `off64_t` to `git_off_t` for internal visibility.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
64 bit types are always 64 bit.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Instead of using a signed type (`off_t`) use an unsigned `uint64_t` for
the size of the files.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Instead of using a signed type (`off_t`) use a new `git_object_size_t`
for the sizes of objects.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Instead of using a signed type (`off_t`) use `uint64_t` for the maximum
size of files.
|
