summaryrefslogtreecommitdiff
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
...
* | Merge pull request #5333 from lrm29/attr_binary_macroPatrick Steinhardt2019-12-131-4/+6
|\ \ | | | | | | attr: Update definition of binary macro
| * | attr: Update definition of binary macroLaurence McGlashan2019-12-121-4/+6
| |/
* | path: support non-ascii drive letters on dosEdward Thomson2019-12-101-0/+11
| | | | | | | | | | | | | | Windows/DOS only supports drive letters that are alpha characters A-Z. However, you can `subst` any one-character as a drive letter, including numbers or even emoji. Test that we can identify emoji as drive letters.
* | index: ensure that we respect core.protectNTFS=falseEdward Thomson2019-12-101-0/+20
| | | | | | | | | | Users may want to turn off core.protectNTFS, perhaps to import (and then repair) a broken tree. Ensure that core.protectNTFS=false is honored.
* | tree: ensure we protect NTFS paths everywhereEdward Thomson2019-12-101-5/+3
| |
* | path: protect NTFS everywhereEdward Thomson2019-12-101-0/+15
| | | | | | | | | | Enable core.protectNTFS by default everywhere and in every codepath, not just on checkout.
* | test: ensure we can't add a protected pathEdward Thomson2019-12-101-0/+56
| | | | | | | | | | Test that when we enable core.protectNTFS that we cannot add platform-specific invalid paths to the index.
* | test: improve badname verification testEdward Thomson2019-12-101-9/+9
| | | | | | | | | | | | The name of the `add_invalid_filename` function suggests that we _want_ to add an invalid filename. Rename the function to show that we expect to _fail_ to add the invalid filename.
* | test: ensure treebuilder validate new protection rulesEdward Thomson2019-12-101-0/+1
| | | | | | | | | | Ensure that the new protection around .git::$INDEX_ALLOCATION rules are enabled for using the treebuilder when core.protectNTFS is set.
* | test: ensure index adds validate new protection rulesEdward Thomson2019-12-101-0/+3
| | | | | | | | | | Ensure that the new protection around .git::$INDEX_ALLOCATION rules are enabled for adding to the index when core.protectNTFS is set.
* | test: improve badname verification testEdward Thomson2019-12-101-12/+12
| | | | | | | | | | | | The name of the `write_invalid_filename` function suggests that we _want_ to write an invalid filename. Rename the function to show that we expect to _fail_ to write the invalid filename.
* | path: also guard `.gitmodules` against NTFS Alternate Data StreamsJohannes Schindelin2019-12-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | We just safe-guarded `.git` against NTFS Alternate Data Stream-related attack vectors, and now it is time to do the same for `.gitmodules`. Note: In the added regression test, we refrain from verifying all kinds of variations between short names and NTFS Alternate Data Streams: as the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it is enough to test one in order to know that all of them are guarded against. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* | Disallow NTFS Alternate Data Stream attacks, even on Linux/macOSJohannes Schindelin2019-12-105-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Protect against 8.3 "short name" attacks also on Linux/macOSJohannes Schindelin2019-12-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows Subsystem for Linux (WSL) is getting increasingly popular, in particular because it makes it _so_ easy to run Linux software on Windows' files, via the auto-mounted Windows drives (`C:\` is mapped to `/mnt/c/`, no need to set that up manually). Unfortunately, files/directories on the Windows drives can be accessed via their _short names_, if that feature is enabled (which it is on the `C:` drive by default). Which means that we have to safeguard even our Linux users against the short name attacks. Further, while the default options of CIFS/SMB-mounts seem to disallow accessing files on network shares via their short names on Linux/macOS, it _is_ possible to do so with the right options. So let's just safe-guard against short name attacks _everywhere_. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* | cl_git_fail: do not report bogus error messageJohannes Schindelin2019-12-101-1/+1
|/ | | | | | | | | | | | | | | | When we expect a checkout operation to fail, but it succeeds, we actually do not want to see the error messages that were generated in the meantime for errors that were handled gracefully by the code (e.g. when an object could not be found in a pack: in this case, the next backend would have been given a chance to look up the object, and probably would have found it because the checkout succeeded, after all). Which means that in the specific case of `cl_git_fail()`, we actually want to clear the global error state _after_ evaluating the command: we know that any still-available error would be bogus, seeing as the command succeeded (unexpectedly). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Merge pull request #5312 from pks-t/pks/patch-base85-overflowEdward Thomson2019-12-012-0/+15
|\ | | | | patch_parse: fix out-of-bounds reads caused by integer underflow
| * patch_parse: fix out-of-bounds reads caused by integer underflowPatrick Steinhardt2019-11-282-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #5311 from pks-t/pks/clar-trace-warningEdward Thomson2019-11-291-10/+16
|\ \ | | | | | | tests: fix compiler warning if tracing is disabled
| * | tests: fix compiler warning if tracing is disabledPatrick Steinhardt2019-11-281-10/+16
| |/ | | | | | | | | | | | | | | 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_SPEEDPatrick Steinhardt2019-11-281-0/+3
|/ | | | | | | | 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.
* Merge pull request #5306 from herrerog/patchidPatrick Steinhardt2019-11-283-0/+77
|\ | | | | diff: complete support for git patchid
| * diff: make patchid computation work with all types of commits.Gregory Herrero2019-11-282-0/+65
| | | | | | | | | | | | | | | | | | | | 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>
| * patch_parse: correct parsing of patch containing not shown binary data.Gregory Herrero2019-11-192-0/+12
| | | | | | | | | | | | | | | | 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>
* | Merge pull request #5243 from pks-t/pks/config-optimize-memPatrick Steinhardt2019-11-282-0/+40020
|\ \ | | | | | | Memory optimizations for config entries
| * | config_entries: micro-optimize storage of multivarsPatrick Steinhardt2019-11-052-0/+40020
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #5309 from libgit2/ethomson/tracePatrick Steinhardt2019-11-281-9/+33
|\ \ \ | | | | | | | | Improve trace support in tests
| * | | tests: optionally show test execution tracingethomson/traceEdward Thomson2019-11-271-1/+9
| | | | | | | | | | | | | | | | | | | | Only show test trace execution when the CLAR_TRACE_TESTS environment variable is set. This reduces the noise during tracing.
| * | | tests: display trace level with prefix in testsEdward Thomson2019-11-271-8/+24
| | | |
* | | | Merge pull request #5123 from libgit2/ethomson/off_tPatrick Steinhardt2019-11-283-3/+3
|\ \ \ \ | |/ / / |/| | | Move `git_off_t` to `git_object_size_t`
| * | | internal: use off64_t instead of git_off_tethomson/off_tEdward Thomson2019-11-253-3/+3
| | |/ | |/| | | | | | | Prefer `off64_t` internally.
* | | test: add an azure repos testEdward Thomson2019-11-241-0/+6
|/ / | | | | | | | | | | | | | | We currently talk to Azure Repos for executing an online test (online::clone::path_whitespace). Add a simpler test to talk to Azure Repos to make it obvious that strange test failures are not likely the whitespace in the path, but actually a function of talking to Azure Repos itself.
* | patch_parse: use paths from "---"/"+++" lines for binary patchesPatrick Steinhardt2019-11-102-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For some patches, it is not possible to derive the old and new file paths from the patch header's first line, most importantly when they contain spaces. In such a case, we derive both paths from the "---" and "+++" lines, which allow for non-ambiguous parsing. We fail to use these paths when parsing binary patches without data, though, as we always expect the header paths to be filled in. Fix this by using the "---"/"+++" paths by default and only fall back to header paths if they aren't set. If neither of those paths are set, we just return an error. Add two tests to verify this behaviour, one of which would have previously caused a segfault.
* | Merge pull request #5299 from pks-t/pks/config-mem-snapshotsEdward Thomson2019-11-061-0/+17
|\ \ | | | | | | config_mem: implement support for snapshots
| * | config_mem: implement support for snapshotsPatrick Steinhardt2019-11-061-0/+17
| |/ | | | | | | | | | | | | | | Similar as in commit dadbb33b6 (Fix crash if snapshotting a config_snapshot, 2019-11-01), let's implement snapshots for in-memory configuration entries. As this deletes more code than it adds, it doesn't make any sense to not allow for this and allows users to treat config backends mostly the same.
* | patch_parse: fix segfault when header path contains whitespace onlyPatrick Steinhardt2019-11-052-0/+26
|/ | | | | | | | | | | | When parsing header paths from a patch, we reject any patches with empty paths as malformed patches. We perform the check whether a path is empty before sanitizing it, though, which may lead to a path becoming empty after the check, e.g. if we have trimmed whitespace. This may lead to a segfault later when any part of our patching logic actually references such a path, which may then be a `NULL` pointer. Fix the issue by performing the check after sanitizing. Add tests to catch the issue as they would have produced a segfault previosuly.
* Merge pull request #5293 from csware/config_snapshot-snapshotPatrick Steinhardt2019-11-051-0/+20
|\ | | | | Fix crash if snapshotting a config_snapshot
| * Fix crash if snapshotting a config_snapshotSven Strickroth2019-11-011-0/+20
| | | | | | | | Signed-off-by: Sven Strickroth <email@cs-ware.de>
* | Merge pull request #5275 from pks-t/pks/reflogs-with-newlinesEdward Thomson2019-11-023-20/+59
|\ \ | | | | | | reflogs: fix behaviour around reflogs with newlines
| * | refdb_fs: properly parse corrupted reflogsPatrick Steinhardt2019-10-181-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In previous versions, libgit2 could be coerced into writing reflog messages with embedded newlines into the reflog by using `git_stash_save` with a message containing newlines. While the root cause is fixed now, it was noticed that upstream git is in fact able to read such corrupted reflog messages just fine. Make the reflog parser more lenient in order to just skip over malformatted reflog lines to bring us in line with git. This requires us to change an existing test that verified that we do indeed _fail_ to parse such logs.
| * | reflog: allow adding entries with newlines in their messagePatrick Steinhardt2019-10-183-3/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the reflog disallows any entries that have a message with newlines, as that would effectively break the reflog format, which may contain a single line per entry, only. Upstream git behaves a bit differently, though, especially when considering stashes: instead of rejecting any reflog entry with newlines, git will simply replace newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will create a reflog entry with "foo bar" as entry message. This commit adjusts our own logic to stop rejecting commit messages with newlines. Previously, this logic was part of `git_reflog_append`, only. There is a second place though where we add reflog entries, which is the serialization code in the filesystem refdb. As it didn't contain any sanity checks whatsoever, the refdb would have been perfectly happy to write malformatted reflog entries to the disk. This is being fixed with the same logic as for the reflog itself.
* | | commit: add failing tests for object checking for git_commit_with_signatureCarlos Martín Nieto2019-10-301-8/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | There can be a significant difference between the system where we created the buffer (if at all) and when the caller provides us with the contents of a commit. Provide some test cases (we have to adapt the existing ones because they refer to trees and commits which do not exist).
* | | Merge pull request #5276 from pks-t/pks/patch-fuzzing-fixesPatrick Steinhardt2019-10-292-0/+54
|\ \ \ | | | | | | | | patch_parse: fixes for fuzzing errors
| * | | patch_parse: detect overflow when calculating old/new line positionPatrick Steinhardt2019-10-212-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the patch contains lines close to INT_MAX, then it may happen that we end up with an integer overflow when calculating the line of the current diff hunk. Reject such patches as unreasonable to avoid the integer overflow. As the calculation is performed on integers, we introduce two new helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform the integer overflow check in a generic way.
| * | | patch_parse: fix out-of-bounds read with No-NL linesPatrick Steinhardt2019-10-191-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've got two locations where we copy lines into the patch. The first one is when copying normal " ", "-" or "+" lines, while the second location gets executed when we copy "\ No newline at end of file" lines. While the first one correctly uses `git__strndup` to copy only until the newline, the other one doesn't. Thus, if the line occurs at the end of the patch and if there is no terminating NUL character, then it may result in an out-of-bounds read. Fix the issue by using `git__strndup`, as was already done in the other location. Furthermore, add allocation checks to both locations to detect out-of-memory situations.
| * | | patch_parse: reject empty path namesPatrick Steinhardt2019-10-192-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When parsing patch headers, we currently accept empty path names just fine, e.g. a line "--- \n" would be parsed as the empty filename. This is not a valid patch format and may cause `NULL` pointer accesses at a later place as `git_buf_detach` will return `NULL` in that case. Reject such patches as malformed with a nice error message.
| * | | patch_parse: reject patches with multiple old/new pathsPatrick Steinhardt2019-10-192-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's currently possible to have patches with multiple old path name headers. As we didn't check for this case, this resulted in a memory leak when overwriting the old old path with the new old path because we simply discarded the old pointer. Instead of fixing this by free'ing the old pointer, we should reject such patches altogether. It doesn't make any sense for the "---" or "+++" markers to occur multiple times within a patch n the first place. This also implicitly fixes the memory leak.
* | | | Merge pull request #5227 from ddevault/checkPatrick Steinhardt2019-10-242-0/+142
|\ \ \ \ | | | | | | | | | | apply: add GIT_APPLY_CHECK
| * | | | apply: add GIT_APPLY_CHECKDrew DeVault2019-10-222-0/+142
| |/ / / | | | | | | | | | | | | | | | | This adds an option which will check if a diff is applicable without actually applying it; equivalent to git apply --check.
* | | | Merge pull request #5264 from henkesn/refs-unlock-on-commitPatrick Steinhardt2019-10-241-0/+26
|\ \ \ \ | |/ / / |/| | | refs: unlock unmodified refs on transaction commit
| * | | refs: unlock unmodified refs on transaction commitSebastian Henke2019-10-171-0/+26
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | Refs which are locked in a transaction without an altered target, still should to be unlocked on `git_transaction_commit`. `git_transaction_free` also unlocks refs but the moment of calling of `git_transaction_free` cannot be controlled in all situations. Some binding libs call `git_transaction_free` on garbage collection or not at all if the application exits before and don't provide public access to `git_transaction_free`. It is better to release locks as soon as possible.
View Lorry Controller Status