| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| | |
stash: avoid recomputing tree when committing worktree
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When creating a new stash, we need to create there separate
commits storing differences stored in the index, untracked
changes as well as differences in the working directory. The
first two will only be done conditionally if the equivalent
options "git stash --keep-index --include-untracked" are being
passed to `git_stash_save`, but even when only creating a stash
of worktree changes we're much slower than git.git. Using our new
stash example:
$ time git stash
Saved working directory and index state WIP on (no branch): 2f7d9d47575e Linux 5.1.7
real 0m0.528s
user 0m0.309s
sys 0m0.381s
$ time lg2 stash
real 0m27.165s
user 0m13.645s
sys 0m6.403s
As can be seen, libgit2 is more than 50x slower than git.git!
When creating the stash commit that includes all worktree
changes, we create a completely new index to prepare for the new
commit and populate it with the entries contained in the index'
tree. Here comes the catch: by populating the index with a tree's
contents, we do not have any stat caches in the index. This means
that we have to re-validate every single file from the worktree
and see whether it has changed.
The issue can be fixed by populating the new index with the
repo's existing index instead of with the tree. This retains all
stat cache information, and thus we really only need to check
files that have changed stat information. This is semantically
equivalent to what we previously did: previously, we used the
tree of the commit computed from the index. Now we're just using
the index directly.
And, in fact, the cache is doing wonders:
time lg2 stash
real 0m1.836s
user 0m1.166s
sys 0m0.663s
We're now performing 15x faster than before and are only 3x
slower than git.git now.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Implement a new example that resembles the git-stash(1) command.
Right now, it only provides the apply, list, save and pop
subcommands without any options.
This example is mostly used to test libgit2's stashing
performance on big repositories.
|
| |\ \
| | |
| | | |
Variadic macros
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The macro `p_snprintf` is implemented as a variadic macro that
calls `snprintf` directly with `__VA_ARGS__`. In C89, variadic
macros are not allowed, but as the arguments of `p_snprintf` and
`snprintf` are matching 1:1, we can fix this by simply removing
the parameter list from `p_snprintf`.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The macro `apply_err` is implemented as a variadic macro, which
are not defined by C89. Convert it to a variadic function,
instead.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The macro `git_parse_error` is implemented in a variadic way so
that it's possible to pass printf-style parameters.
Unfortunately, variadic macros are not defined by C89 and thus we
cannot use that functionality. But as we have implemented
`git_error_vset` in the previous commit, we can now just use that
instead.
Convert `git_parse_error` to a variadic function and use
`git_error_vset` to fix the compliance violation. While at it,
move the function to "patch_parse.c".
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Right now, we only provide a `git_error_set` that has a variadic
function signature. It's impossible to drive this function in a
C89-compliant way from other functions that have a variadic
signature, though, like for example `git_parse_error`.
Implement a new `git_error_vset` function that gets a `va_list`
as parameter, fixing the above problem.
|
| |\ \ \
| | | |
| | | | |
Add sign capability to git_rebase_commit
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Use ci_git_fail_with where appropriate.
Use correct initializer for callback.
|
| | | | |
| | | |
| | | |
| | | | |
This simplifies the flow of rebase_commit__create because it doesn't have to juggle 2 different commit flows (one with signature and one without).
|
| | | | |
| | | |
| | | |
| | | | |
If provided with a null signature, skip adding the signature header and create the commit anyway.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We should clear the error before calling the signing_cb to allow the signing_cb to set its own errors. If the CB did not provide an error, we should set our own generic error before exiting rebase_commit__create
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
In the case that we want to build merge + commit, cherrypick + commit, or even just build a commit with signing callback, `git_rebase_commit_signature_cb` particular callback should be made more generic. We also renamed `signature_cb` to `signing_cb` to improve clarity on the purpose of the callback (build a difference between a git_signature and the act of signing).
So we've ended up with `git_commit_signing_cb`.
|
| | | | | |
|
| | | | |
| | | |
| | | | |
Reduces the number of callbacks for signing a commit during a rebase operation to just one callback. That callback has 2 out git_buf parameters for signature and signature field. We use git_buf here, because we cannot make any assumptions about the heap allocator a user of the library might be using.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
2 callbacks have been added to git_rebase_options, git_rebase_commit_signature_cb and git_rebase_commit_signature_field_cb. When git_rebase_commit_signature_cb is present in git_rebase_options, it will be called whenever git_rebase_commit is performed, giving an opportunity to sign the commit. The signing procedure can be skipped if the callback specifies passthrough as the error. The git_rebase_commit_signature_field_cb will only be called if the other callback is present or did not passthrough, and it provides means to specify which field a signature is for.
Git_rebase_options was chosen as the home for these callbacks as it keeps backwards compatibility with the current rebase api.
|
| |\ \ \ \
| | | | |
| | | | | |
remote: remove unused block of code
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In "remote.c", we have a chunk of code that is #ifdef'fed out via
`#if 0` with a comment that we could export it as a helper function.
The code was implemented in 2013 and ifdef'fed in 2014, which shows that
there's clearly no interest in having such a helper at all.
As this block has recently created some confusion about `p_getenv` due
to it containing the only reference to that function in our codebase,
let's remove this block altogether.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Adjust printf specifiers in examples code
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Static analysis of example code found multiple findings of `printf` usage
where filling value is members of git_indexer_progress object. Specifier
used was for signed int but git_indexer_progress members are typed as
unsigned ints. `printf` specifiers were altered to match type.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
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.
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
Fix example checkout to forbid rather than require --
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Make the example program for checkout follow git syntax, where
"--" indicates a file. This was likely just a strcmp return
value confusion.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
editorconfig: update to match our coding style
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Update editorconfig to match our coding style. Most importantly, we set
up the tab width to be 8 characters instead of the default and use
2 spaces to indent YAML files.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Compare buffers in diff example
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Consolidate all standard includes and defines into "common.h". This lets
us avoid having to handle platform-specific things in multiple places.
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | | |
Include ahead_behind in the test suite
|
| | | |_|/ / /
| |/| | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
config: separate file and snapshot backends
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The internal backend structures are kind-of legacy and do not really
speak for themselves. Rename them accordingly to make them easier to
understand.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
To further distinguish the file writeable and readonly backends,
separate the readonly backend into its own "config_snapshot.c"
implementation. The snapshot backend can be generically used to snapshot
any type of backend.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In `backend_readonly_free`, the passed in config backend is being cast
to a `diskfile_backend` instead of to a `diskfile_readonly_backend`.
While this works out just fine because we only access its header values,
which were shared between both backends, it is undefined behaviour.
Use the correct type to fix this.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The `diskfile_header` structure is shared between both
`diskfile_backend` and `diskfile_readonly_backend`. The separation and
resulting casting is confusing at times and a source for programming
errors.
Remove the shared structure and inline them directly.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
While most functions of the readonly configuration backend are
implemented separately from the writeable configuration backend, the two
functions `config_iterator_new` and `config_get` are shared between
both. This sharing makes it necessary to have some shared data
structures, which is the `diskfile_header` structure. Unfortunately, this
makes the backends harder to grasp than necessary due to all the casting
between structs and also quite error prone.
Reimplement those functions for the readonly backends. As readonly
backends cannot be refreshed anyway, we can remove the calls to
`config_refresh` in there.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The `config_readonly_open` function currently receives as input a
diskfile backend and will copy its entries to a new snapshot. This is
rather intimate, as we need to assume that the source config backend is
in fact a diskfile entry. We can do better than this though by using
generic methods to copy contents of the provided backend, e.g. by using
a config iterator. This also allows us to decouple the read-only backend
from the read-write backend.
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When duplicating a configuration entry, we allocate a new entry but do
not verify that we get a valid pointer back. As we're dereferencing the
pointer afterwards, we might thus run into a segfault in out-of-memory
situations.
Extract a new function `git_config_entries_dup_entry` that handles the
complete entry duplication. Fix the error by using
`GIT_ERROR_CHECK_ALLOC`.
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
object: deprecate git_object__size for removal
|
