Don't munge the "trivial" tests, those are specifically about the
"trivial" resolutions for git's tree merge. (For example, adding a file
in a new branch and making no changes in the HEAD branch is something
that can be handled _trivially_.)
For tests of rename functionality, put them in the trees::rename tests.
Keep the push options tests more constrained to our CI environment;
writing files within the test sandbox instead of outside of it. Provide
the path to the output file in the test data. In addition, add the
repository to the test resources instead of recreating the hooks every
time.
Test that we can successfully clone a repository that is namespace
scoped to a bare repository locally. We need not specify a checkout
branch in this case (obviously, since we do not check anything out in a
bare clone).
`git_reference_cmp` only considers the target of a reference, and
ignores the name. Meaning that a reference `foo` and reference `bar`
pointing to the same commit will compare equal.
Correct this, comparing the name _and_ target of a reference.
Currently ref lookups require loading the entire packed-refs file into
a hashmap in memory. For repos with large numbers of refs this can be
painfully slow.
This patch replaces the existing lookup code and instead mmap()'s the
packed-refs file and performs a binary search to locate the ref entry.
Git uses a similiar approach.
The old hash table codepath is still used for unsorted packed-refs files.
This patch also fixes a minor bug where the "peeled" trait is never
parsed correctly from the packed-refs header.
we want to test:
- an anonymous repo (a url)
- a named repo with a url
- a named repo with a url and pushurl
and for each of these matching configuration:
- only insteadOf
- only pushInsteadOf
- both insteadOf and pushInsteadOf
this change adds test cases for all of these combinations.
This change introduces `git_commit_graph_entry_find()` and
`git_commit_graph_entry_parent()`. These two functions allow a much
faster lookup of commits by ID, since the ODB does not need to be
consulted, the commit object does not need to be inflated, and the
contents of the commit object do not need to be parsed.
Part of: #5757
This change is the first in a series to add support for git's
commit-graph. This should speed up commit graph traversals by avoiding
object parsing and allowing some operations to terminate earlier.
Part of: #5757
This change makes sure that the hunk is not null before trying to
dereference it. This avoids segfaults, especially when blaming against a
modified buffer (i.e. the index).
Fixes: #5443
This requires adding a new symbolic ref to the testrepo fixture.
Some of the existing tests attempt to delete HEAD, expecting a different failure. Introduce and use a non-HEAD symbolic ref instead.
Adjust a few other tests as needed.
Fixes#5357
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>
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.
The code worked under the assumption that anything under `refs/tags` are
tag objects, and all the rest would be peelable to a commit. As it is
completely valid to have tags to blobs under a non `refs/tags` ref, this
would cause failures when trying to peel a tag to a commit.
Fix the broken filtering by switching to `git_revwalk_push_glob`, which
already handles this case.
