- 09 Jan, 2017 3 commits
-
-
Security updates for v0.24
Carlos Martín Nieto committed -
None of our crypto backends actually reject RC4 as a cipher so don't test for it and instead keep it as something we'd like to do.
Carlos Martín Nieto committed -
We must make sure that we're getting a certificate error from the library so we know that we're testing the right thing.
Carlos Martín Nieto committed
-
- 06 Jan, 2017 7 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-
The Git protocol does not specify what should happen in the case of an empty packet line (that is a packet line "0004"). We currently indicate success, but do not return a packet in the case where we hit an empty line. The smart protocol was not prepared to handle such packets in all cases, though, resulting in a `NULL` pointer dereference. Fix the issue by returning an error instead. As such kind of packets is not even specified by upstream, this is the right thing to do.
Patrick Steinhardt committed -
Each packet line in the Git protocol is prefixed by a four-byte length of how much data will follow, which we parse in `git_pkt_parse_line`. The transmitted length can either be equal to zero in case of a flush packet or has to be at least of length four, as it also includes the encoded length itself. Not checking this may result in a buffer overflow as we directly pass the length to functions which accept a `size_t` length as parameter. Fix the issue by verifying that non-flush packets have at least a length of `PKT_LEN_SIZE`.
Patrick Steinhardt committed -
Make sure that the callbacks do also get a 'valid' value of zero when the certificate we're looking at is in valid and assert that within the test.
Carlos Martín Nieto committed -
Etienne Samson committed
-
- 17 Dec, 2016 1 commit
-
-
Carlos Martín Nieto committed
-
- 16 Dec, 2016 2 commits
-
-
Carlos Martín Nieto committed
-
Add support for OpenSSL 1.1.0 for BIO filter
Carlos Martín Nieto committed
-
- 19 Nov, 2016 1 commit
-
-
Carlos Martín Nieto committed
-
- 03 Nov, 2016 5 commits
-
-
Carlos Martín Nieto committed
-
Backport the object parsing fixes
Carlos Martín Nieto committed -
The Mac machines have updated their SSH version and so the ssh-keygen format has changed. Ask it for MD5, which is the one that is output as hex.
Carlos Martín Nieto committed -
When parsing a commit, we will treat all bytes left after parsing the headers as the commit message. When no bytes are left, we leave the commit's message uninitialized. While uncommon to have a commit without message, this is the right behavior as Git unfortunately allows for empty commit messages. Given that this scenario is so uncommon, most programs acting on the commit message will never check if the message is actually set, which may lead to errors. To work around the error and not lay the burden of checking for empty commit messages to the developer, initialize the commit message with an empty string when no commit message is given.
Patrick Steinhardt committed -
When parsing tree entries from raw object data, we do not verify that the tree entry actually has a filename as well as a valid object ID. Fix this by asserting that the filename length is non-zero as well as asserting that there are at least `GIT_OID_RAWSZ` bytes left when parsing the OID.
Patrick Steinhardt committed
-
- 02 Oct, 2016 5 commits
-
-
Carlos Martín Nieto committed
-
Some CI fixes for the maint/v0.24 branch
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
Backport fixes to v0.24
Edward Thomson committed
-
- 01 Oct, 2016 16 commits
-
-
When the array is empty `cmp` never gets set by the comparison function. Initialize it so we return ENOTFOUND in those cases.
Carlos Martín Nieto committed -
Only provide the empty tree internally, which matches git's behavior. If we provide the empty blob then any users trying to write it with libgit2 would omit it from actually landing in the odb, which appear to git proper as a broken repository (missing that object).
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
The `PKG_CHECK_MODULES` function searches a pkg-config module and then proceeds to set various variables containing information on how to link to the library. In contrast to the `FIND_PACKAGE` function, the library path set by `PKG_CHECK_MODULES` will not necessarily contain linking instructions with a complete path to the library, though. So when a library is not installed in a standard location, the linker might later fail due to being unable to locate it. While we already honor this when configuring libssh2 by adding `LIBSSH2_LIBRARY_DIRS` to the link directories, we fail to do so for libcurl, preventing us to build libgit2 on e.g. FreeBSD. Fix the issue by adding the curl library directory to the linker search path.
Patrick Steinhardt committed -
According to the reference the git_checkout_tree and git_checkout_head functions should accept NULL in the opts field This was broken since the opts field was dereferenced and thus lead to a crash.
Stefan Huber committed -
When calling `http_connect` on a subtransport whose stream is already connected, we first close the stream in case no keep-alive is in use. When doing so, we do not reset the transport's connection state, though. Usually, this will do no harm in case the subsequent connect will succeed. But when the connection fails we are left with a substransport which is tagged as connected but which has no valid stream attached. Fix the issue by resetting the subtransport's connected-state when closing its stream in `http_connect`.
Patrick Steinhardt committed -
The .gitignore file allows for patterns which unignore previous ignore patterns. When unignoring a previous pattern, there are basically three cases how this is matched when no globbing is used: 1. when a previous file has been ignored, it can be unignored by using its exact name, e.g. foo/bar !foo/bar 2. when a file in a subdirectory has been ignored, it can be unignored by using its basename, e.g. foo/bar !bar 3. when all files with a basename are ignored, a specific file can be unignored again by specifying its path in a subdirectory, e.g. bar !foo/bar The first problem in libgit2 is that we did not correctly treat the second case. While we verified that the negative pattern matches the tail of the positive one, we did not verify if it only matches the basename of the positive pattern. So e.g. we would have also negated a pattern like foo/fruz_bar !bar Furthermore, we did not check for the third case, where a basename is being unignored in a certain subdirectory again. Both issues are fixed with this commit.
Patrick Steinhardt committed -
When failing to initialize a new stransport stream, we try to release already allocated memory by calling out to `git_stream_free`, which in turn called out to the stream's `free` function pointer. As we only initialize the function pointer later on, this leads to a `NULL` pointer exception. Furthermore, plug another memory leak when failing to create the SSL context.
Patrick Steinhardt committed -
Patrick Steinhardt committed
-
The `SSLCopyPeerTrust` call can succeed but fail to return a trust object if it can't load the certificate chain and thus cannot check the validity of a certificate. This can lead to us calling `CFRelease` on a `NULL` trust object, causing a crash. Handle this by returning ECERTIFICATE.
Carlos Martín Nieto committed -
Don't try to determine when sysdirs are uninitialized. Instead, simply initialize them all at `git_libgit2_init` time and never try to reinitialize, except when consumers explicitly call `git_sysdir_set`. Looking at the buffer length is especially problematic, since there may no appropriate path for that value. (For example, the Windows-specific programdata directory has no value on non-Windows machines.) Previously we would continually trying to re-lookup these values, which could get racy if two different threads are each calling `git_sysdir_get` and trying to lookup / clear the value simultaneously.
Edward Thomson committed -
According to git-fetch(1), "[t]he colon can be omitted when <dst> is empty." So according to git, the refspec "refs/heads/master" is the same as the refspec "refs/heads/master:" when fetching changes. When trying to fetch from a remote with a trailing colon with libgit2, though, the fetch actually fails while it works when the trailing colon is left out. So obviously, libgit2 does _not_ treat these two refspec formats the same for fetches. The problem results from parsing refspecs, where the resulting refspec has its destination set to an empty string in the case of a trailing colon and to a `NULL` pointer in the case of no trailing colon. When passing this to our DWIM machinery, the empty string gets translated to "refs/heads/", which is simply wrong. Fix the problem by having the parsing machinery treat both cases the same for fetch refspecs.
Patrick Steinhardt committed -
And give it a default so that some compilers don't (unnecessarily) complain.
Edward Thomson committed -
Somehow I ended up with the following in my ~/.gitconfig: [branch "master"] remote = origin merge = master rebase = true I assume something went crazy while I was running the git.git tests some time ago, and that I never noticed until now. This is not a good configuration, but it shouldn't cause problems. But it does. Specifically, if you have this in your config, and you perform the following set of actions: create a remote fetch from that remote create a branch off of the remote master branch called "master" delete the branch delete the remote The remote delete fails with the message "Could not find key 'branch.master.rebase' to delete". This is because it's iterating over the config entries (including the ones in the global config) and believes that there is a master branch which must therefore have these config keys. https://github.com/libgit2/libgit2/issues/3856
David Turner committed -
When we create a blame origin, we try to look up the blob that is to be blamed at a certain revision. When this lookup fails, e.g. because the file did not exist at that certain revision, we fail to create the blame origin and return `NULL`. The blame origin that we have just allocated is thereby free'd with `origin_decref`. The `origin_decref` function does not only decrement reference counts for the blame origin, though, but also for its commit and blob. When this is done in the error case, we will cause an uneven reference count for these objects. This may result in hard-to-debug failures at seemingly unrelated code paths, where we try to access these objects when they in fact have already been free'd. Fix the issue by refactoring `make_origin` such that we only allocate the object after the only function that may fail so that we do not have to call `origin_decref` at all. Also fix the `pass_blame` function, which indirectly calls `make_origin`, to free the commit when `make_origin` failed.
Patrick Steinhardt committed
-