summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | patch_parse: use paths from "---"/"+++" lines for binary patchesPatrick Steinhardt2019-11-101-5/+11
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #5285 from pcpthm/winhttp-308Edward Thomson2019-11-161-1/+6
|\ \ \ \ | | | | | | | | | | Follow 308 redirect in WinHTTP transport
| * | | | Follow 308 redirect in WinHTTP transportpcpthm2019-10-261-1/+6
| | | | |
* | | | | Merge pull request #5302 from tiennou/fix/p_lstat-errnoEdward Thomson2019-11-161-0/+1
|\ \ \ \ \ | |_|/ / / |/| | | | fileops: correct error return on p_lstat failures when mkdir
| * | | | fileops: correct error return on p_lstat failures when mkdirEtienne Samson2019-11-091-0/+1
| | |/ / | |/| | | | | | | | | | | | | | | | | | IIRC I got a strange return once from lstat, which translated in a weird error class/message being reported. As a safety measure, enforce a -1 return in that case.
* | | | Merge pull request #5299 from pks-t/pks/config-mem-snapshotsEdward Thomson2019-11-061-9/+1
|\ \ \ \ | | | | | | | | | | config_mem: implement support for snapshots
| * | | | config_mem: implement support for snapshotsPatrick Steinhardt2019-11-061-9/+1
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-051-12/+9
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | config_file: keep reference to config entries when creating iteratorPatrick Steinhardt2019-11-051-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When creating a configuration file iterator, then we first refresh the backend and then afterwards duplicate all refreshed configuration entries into the iterator in order to avoid seeing any concurrent modifications of the entries while iterating. The duplication of entries is not guarded, though, as we do not increase the refcount of the entries that we duplicate right now. This opens us up for a race, as another thread may concurrently refresh the repository configuration and thus swap out the current set of entries. As we didn't increase the refcount, this may lead to the entries being free'd while we iterate over them in the first thread. Fix the issue by properly handling the lifecycle of the backend's entries via `config_file_entries_take` and `git_config_entries_free`, respectively.
* | | config_file: refactor taking entries ref to return an error codePatrick Steinhardt2019-11-051-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function to take a reference to the config file's config entries currently returns the reference via return value. Due to this, it's harder than necessary to integrate into our typical coding style, as one needs to make sure that a proper error code is set before erroring out from the caller. This bites us in `config_file_delete`, where we call `goto out` directly when `config_file_entries_take` returns `NULL`, but we actually forget to set up the error code and thus return success. Fix the issue by refactoring the function to return an error code and pass the reference via an out-pointer.
* | | config_file: remove unused includesPatrick Steinhardt2019-11-051-6/+0
| | |
* | | config_file: rename function namesPatrick Steinhardt2019-11-051-58/+63
| | | | | | | | | | | | | | | | | | | | | As with the predecessing commit, this commit renames backend functions of the configuration file backend. This helps to clearly separate functionality and also to be able to see from backtraces which backend is currently in use.
* | | config_snapshot: rename function namesPatrick Steinhardt2019-11-051-22/+22
| |/ |/| | | | | | | | | | | | | The configuration snapshot backend has been extracted from the old files backend back in 2bff84ba4 (config_file: separate out read-only backend, 2019-07-26). To keep code churn manageable, the local functions weren't renamed yet and thus still have references to the old diskfile backend. Rename them accordingly to make them easier to understand.
* | Merge pull request #5293 from csware/config_snapshot-snapshotPatrick Steinhardt2019-11-051-0/+1
|\ \ | | | | | | Fix crash if snapshotting a config_snapshot
| * | Fix crash if snapshotting a config_snapshotSven Strickroth2019-11-011-0/+1
| | | | | | | | | | | | Signed-off-by: Sven Strickroth <email@cs-ware.de>
* | | fix a bug introduced in 8a23597bromkatv2019-11-051-1/+1
| | |
* | | Merge pull request #5275 from pks-t/pks/reflogs-with-newlinesEdward Thomson2019-11-025-112/+96
|\ \ \ | | | | | | | | reflogs: fix behaviour around reflogs with newlines
| * | | refdb_fs: properly parse corrupted reflogsPatrick Steinhardt2019-10-181-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | refdb_fs: convert reflog parsing to use parserPatrick Steinhardt2019-10-183-44/+42
| | | | | | | | | | | | | | | | | | | | The refdb_fs code to parse the reflog currently uses a hand-rolled parser. Convert it to use our `git_parse_ctx` structure instead.
| * | | reflog: allow adding entries with newlines in their messagePatrick Steinhardt2019-10-182-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | stash: refactor code that prepares commit messagesPatrick Steinhardt2019-10-181-18/+15
| | | |
| * | | stash: modernize code style of `git_stash_save`Patrick Steinhardt2019-10-181-32/+15
| | | | | | | | | | | | | | | | | | | | The code style of `git_stash_save` doesn't really match our current coding style. Update it to match our current policies more closely.
* | | | commit: verify objects exist in git_commit_with_signaturecmn/create-with-signature-verificationCarlos Martín Nieto2019-10-301-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Verify that the commit we are being asked to create references objects which do exist in the target repository.
* | | | Merge pull request #5276 from pks-t/pks/patch-fuzzing-fixesPatrick Steinhardt2019-10-292-7/+62
|\ \ \ \ | |_|_|/ |/| | | patch_parse: fixes for fuzzing errors
| * | | patch_parse: detect overflow when calculating old/new line positionPatrick Steinhardt2019-10-212-4/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-191-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-241-3/+7
|\ \ \ \ | | | | | | | | | | apply: add GIT_APPLY_CHECK
| * | | | apply: add GIT_APPLY_CHECKDrew DeVault2019-10-221-3/+7
| |/ / / | | | | | | | | | | | | | | | | 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-1/+7
|\ \ \ \ | |/ / / |/| | | refs: unlock unmodified refs on transaction commit
| * | | refs: unlock unmodified refs on transaction commitSebastian Henke2019-10-171-1/+7
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #5273 from dlax/parse-diff-without-extended-headersPatrick Steinhardt2019-10-171-0/+1
|\ \ \ | | | | | | | | patch_parse: handle patches without extended headers
| * | | patch_parse: handle patches without extended headersDenis Laxalde2019-10-161-0/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | Extended header lines (especially the "index <hash>..<hash> <mode>") are not required by "git apply" so it import patches. So we allow the from-file/to-file lines (--- a/file\n+++ b/file) to directly follow the git diff header. This fixes #5267.
* | | submodule: provide a wrapper for simple submodule clone stepsEtienne Samson2019-10-173-3/+85
| | |
* | | negotiate: use GSS.framework on macOSEtienne Samson2019-10-134-11/+10
| | |
* | | cmake: remove extra GIT_NTLM defineEtienne Samson2019-10-131-2/+1
| | |
* | | util: hide helper qsort code to silence unused functions warningEtienne Samson2019-10-131-0/+5
|/ /
* | Merge pull request #5257 from henkesn/masterPatrick Steinhardt2019-10-117-19/+15
|\ \ | | | | | | Fix file locking on POSIX OS
| * | refs: fix locks getting forcibly removedSebastian Henke2019-10-107-19/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The flag GIT_FILEBUF_FORCE currently does two things: 1. It will cause the filebuf to create non-existing leading directories for the file that is about to be written. 2. It will forcibly remove any pre-existing locks. While most call sites actually do want (1), they do not want to remove pre-existing locks, as that renders the locking mechanisms effectively useless. Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to separate both behaviours cleanly from each other and convert callers to use it instead of `GIT_FILEBUF_FORCE` to have them honor locked files correctly. As this conversion removes all current users of `GIT_FILEBUF_FORCE`, this commit removes the flag altogether.
* | | Merge pull request #5260 from pks-t/pks/cmake3Patrick Steinhardt2019-10-111-10/+2
|\ \ \ | | | | | | | | cmake: update minimum CMake version to v3.5.1
| * | | cmake: update minimum CMake version to v3.5.1Patrick Steinhardt2019-10-101-10/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in commit cf9f34521 (cmake: bump minimum version to 2.8.11, 2017-09-06), we have bumped the minimum CMake version to require at least v2.8.11. The main hold-backs back then were distributions like RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6 has CMake v3.6.1 available via the EPEL6 repository, and thus it seems fair to upgrade to a more recent version. Going through repology [1], one can see that all supported mainstream distributions do in fact have CMake 3 available. Going through the list, the minimum version that is supported by all mainstream distros is in fact v3.5.1: - CentOS 6 via EPEL6: 3.6.1 - Debian Oldstable: 3.7.2 - Fedora 26: 3.8.2 - OpenMandriva 3.x: 3.5.1 - Slackware 14.2: 3.5.2 - Ubuntu 16.04: 3.5.1 Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and remove all the version CMake checks that aren't required anymore. [1]: https://repology.org/project/cmake/versions
* | | Merge pull request #5248 from dlax/parse-patch-empty-filesPatrick Steinhardt2019-10-101-0/+1
|\ \ \ | |/ / |/| | patch_parse: handle patches with new empty files
| * | patch_parse: handle patches with new empty filesDenis Laxalde2019-09-281-0/+1
| | | | | | | | | | | | | | | | | | | | | Patches containing additions of empty files will not contain diff data but will end with the index header line followed by the terminating sequence "-- ". We follow the same logic as in cc4c44a and allow "-- " to immediately follow the index header.
* | | Merge pull request #4445 from tiennou/shallow/dry-commit-parsingPatrick Steinhardt2019-10-035-89/+76
|\ \ \ | | | | | | | | DRY commit parsing
| * | | commit_list: store in/out-degrees as uint16_tPatrick Steinhardt2019-10-033-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit list's in- and out-degrees are currently stored as `unsigned short`. When assigning it the value of `git_array_size`, which returns an `size_t`, this generates a warning on some Win32 platforms due to loosing precision. We could just cast the returned value of `git_array_size`, which would work fine for 99.99% of all cases as commits typically have less than 2^16 parents. For crafted commits though we might end up with a wrong value, and thus we should definitely check whether the array size actually fits into the field. To ease the check, let's convert the fields to store the degrees as `uint16_t`. We shouldn't rely on such unspecific types anyway, as it may lead to different behaviour across platforms. Furthermore, this commit introduces a new `git__is_uint16` function to check whether it actually fits -- if not, we return an error.
| * | | commit_list: unify commit information parsingEtienne Samson2019-10-031-77/+23
| | | |
| * | | commit: generic parse mechanismEtienne Samson2019-10-032-11/+39
| | | | | | | | | | | | | | | | | | | | | | | | This allows us to pick which data from a commit we're interested in. This will be used by the revwalk code, which is only interested in parents' and committer data.
* | | | Merge pull request #5226 from pks-t/pks/regexp-apiEdward Thomson2019-09-2811-177/+384
|\ \ \ \ | |_|/ / |/| | | regexp: implement a new regular expression API
| * | | posix: remove superseded POSIX regex wrappersPatrick Steinhardt2019-09-214-96/+0
| | | | | | | | | | | | | | | | | | | | | | | | The old POSIX regex wrappers have been superseded by our own regexp API that provides a higher-level abstraction. Remove the POSIX wrappers in favor of the new one.
View Lorry Controller Status