summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* transport: allow cred/cert callbacks to return >0origin/ethomson/defer_cert_cred_cb_0_27Edward Thomson2018-11-064-6/+30
| | | | | | | | | | | | | | Allow credential and certificate checking callbacks to return > 0, indicating that they did not want to act. This was documented in the credential acquisition callback already, but only loosely implemented. Expand this to being supported in the http and ssh callbacks. Additionally, enable the same mechanism for certificate validation. This is useful to disambiguate any meaning for returning > 0 in the publicly exposed credential and certificate functions (`git_transport_smart_certificate_check`) and (`git_transport_smart_credentials`). But it may be more generally useful for callers to be able to defer back to libgit2.
* transport: see if cert/cred callbacks exist before calling themEdward Thomson2018-11-062-2/+18
| | | | | | | Custom transports may want to ask libgit2 to invoke a configured credential or certificate callback; however they likely do not know if a callback was actually configured. Return a sentinal value (greater than zero) if there is no callback configured instead of crashing.
* Merge pull request #4846 from pks-t/pks/v0.27.6v0.27.7Patrick Steinhardt2018-10-2629-66/+457
|\ | | | | Bugix release v0.27.7
| * version: bump to v0.27.7Patrick Steinhardt2018-10-261-2/+2
| |
| * CHANGELOG: update for v0.27.7Patrick Steinhardt2018-10-261-0/+45
| |
| * winhttp: retry erroneously failing requestsEdward Thomson2018-10-261-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | Early Windows TLS 1.2 implementations have an issue during key exchange with OpenSSL implementations that cause negotiation to fail with the error "the buffer supplied to a function was too small." This is a transient error on the connection, so when that error is received, retry up to 5 times to create a connection to the remote server before actually giving up. (cherry picked from commit dc371e3c5903760cc2334a0acfac9bce04479773)
| * git_remote_prune to be O(n * logn)Marcin Krystianc2018-10-261-1/+1
| | | | | | | | (cherry picked from commit bfec6526e931d7f6ac5ecc38c37e76163092bfda)
| * ignore unsupported http authentication schemesAnders Borum2018-10-261-1/+4
| | | | | | | | | | | | | | | | | | | | | | auth_context_match returns 0 instead of -1 for unknown schemes to not fail in situations where some authentication schemes are supported and others are not. apply_credentials is adjusted to handle auth_context_match returning 0 without producing authentication context. (cherry picked from commit 475db39bb4c44a2221f340c66c227f555e478d10)
| * transport/http: do not return success if we failed to get a schemeEtienne Samson2018-10-261-1/+1
| | | | | | | | | | | | | | Otherwise we return a NULL context, which will get dereferenced in apply_credentials. (cherry picked from commit 1c949ce1483ca22a29e8f523360999cbbe411a50)
| * cmake: explicitly enable int-conversion warningsPatrick Steinhardt2018-10-261-0/+1
| | | | | | | | | | | | | | | | | | | | While GCC enables int-conversion warnings by default, it will currently only warn about such errors even in case where "-DENABLE_WERROR=ON" has been passed to CMake. Explicitly enable int-conversion warnings by using our `ENABLE_WARNINGS` macro, which will automatically use "-Werror=int-conversions" in case it has been requested by the user. (cherry picked from commit aa0ae59a2a31dc0ee5cc987066903d135a5f9e79)
| * tests: fix warning for implicit conversion of integer to pointerPatrick Steinhardt2018-10-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | GCC warns by default when implicitly converting integers to pointers or the other way round, and commit fa48d2ea7 (vector: do not malloc 0-length vectors on dup, 2018-09-26) introduced such an implicit conversion into our vector tests. While this is totally fine in this test, as the pointer's value is never being used in the first place, we can trivially avoid the warning by instead just inserting a pointer for a variable allocated on the stack into the vector. (cherry picked from commit dbb4a5866fcbb121000a705e074f679445d6916b)
| * cmake: enable -Wformat and -Wformat-securityCarlos Martín Nieto2018-10-261-0/+2
| | | | | | | | | | | | | | We do not currently have any warnings in this regard, but it's good practice to have them on in case we introduce something. (cherry picked from commit f2c1153d4fa09a36be7c6b87e4f55325f6e5031e)
| * fix check if blob is uninteresting when inserting tree to packbuilderAnders Borum2018-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | Blobs that have been marked as uninteresting should not be inserted into packbuilder when inserting a tree. The check as to whether a blob was uninteresting looked at the status for the tree itself instead of the blob. This could cause significantly larger packfiles. (cherry picked from commit b36cc7a4013a47856dade4226edc657906b82431)
| * revwalk: only check the first commit in the list for an earlier timestampCarlos Martín Nieto2018-10-261-2/+8
| | | | | | | | | | | | | | | | | | This is not a big deal, but it does make us match git more closely by checking only the first. The lists are sorted already, so there should be no functional difference other than removing a possible check from every iteration in the loop. (cherry picked from commit 12a1790d8e71087056d2b2de936ddae439e1d94c)
| * revwalk: use the max value for a signed integerCarlos Martín Nieto2018-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When porting, we overlooked that the difference between git's and our's time representation and copied their way of getting the max value. Unfortunately git was using unsigned integers, so `~0ll` does correspond to their max value, whereas for us it corresponds to `-1`. This means that we always consider the last date to be smaller than the current commit's and always think commits are interesting. Change the initial value to the macro that gives us the maximum value on each platform so we can accurately consider commits interesting or not. (cherry picked from commit 46f35127b6fcfab87cb80d1b772ac7c662eafd38)
| * vector: do not realloc 0-size vectorsEtienne Samson2018-10-261-0/+3
| | | | | | | | (cherry picked from commit e0afd1c21c4421cec4f67162021f835e2bbb7df6)
| * vector: do not malloc 0-length vectors on dupEtienne Samson2018-10-262-8/+29
| | | | | | | | (cherry picked from commit fa48d2ea7d2d5dc9620e5c9f05ba8d788775582b)
| * index: release the snapshot instead of freeing the indexEtienne Samson2018-10-261-1/+1
| | | | | | | | | | | | | | | | Previously we would assert in index_free because the reader incrementation would not be balanced. Release the snapshot normally, so the variable gets decremented before the index is freed. (cherry picked from commit c70713d6e4af563696563e410864eb4a6507757d)
| * cmake: detect and use libc-provided iconvPatrick Steinhardt2018-10-261-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While most systems provide a separate iconv library against which applications can link, musl based systems do not provide such a library. Instead, iconv functions are directly included in the C library. As our current CMake module to locate the iconv library only checks whether a library exists somewhere in the typical library directories, we will never build libgit2 with libiconv support on such systems. Extend the iconv module to also search whether libc provides iconv functions, which we do by checking whether the `iconv_open` function exists inside of libc. If this is the case, we will default to use the libc provided one instead of trying to use a separate libiconv. While this changes which iconv we use on systems where both libc and an external libiconv exist, to the best of my knowledge common systems only provide either one or the other. Note that libiconv support in musl is held kind of basic. To quote musl libc's page on functional differences from glibc [1]: The iconv implementation musl is very small and oriented towards being unobtrusive to static link. Its character set/encoding coverage is very strong for its size, but not comprehensive like glibc’s. As we assume iconv to be a lot more capable than what musl provides, some of our tests will fail if using iconv on musl-based platforms. [1]: https://wiki.musl-libc.org/functional-differences-from-glibc.html (cherry picked from commit 2e2d8c6493ec4d151c55d7421c93126267ee8e6d)
| * remote: set the error before cleanupEtienne Samson2018-10-261-2/+2
| | | | | | | | | | | | Otherwise we'll return stack data to the caller. (cherry picked from commit 22d013b657c5957fde31641351cb72d08cc192ae)
| * revwalk: The left operand of '<' is a garbage valueEtienne Samson2018-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | At line 594, we do this : if (error < 0) return error; but if nothing was pushed in a GIT_SORT_TIME revwalk, we'd return uninitialized stack data. (cherry picked from commit aa8cb5866f1eabd92c8c08f7a8610d42df07375f)
| * worktree: unlock should return 1 when the worktree isn't lockedEtienne Samson2018-10-262-3/+3
| | | | | | | | | | | | | | | | The documentation states that git_worktree_unlock returns 0 on success, and 1 on success if the worktree wasn't locked. Turns out we were returning 0 in any of those cases. (cherry picked from commit 59c2e70eeee8b2bae79d05060599114a5f6d737a)
| * Fix leak in index.cabyss72018-10-261-1/+2
| | | | | | | | (cherry picked from commit 581d5492f6afdaf31a10e51187466a80ffc9f76f)
| * util: make the qsort_r check work on macOSEtienne Samson2018-10-265-7/+142
| | | | | | | | | | | | | | | | | | | | This performs a compile-check by using CMake support, to differentiate the GNU version from the BSD version of qsort_r. Module taken from 4f252abea5f1d17c60f6ff115c9c44cc0b6f1df6, which I've checked against CMake 2.8.11. (cherry picked from commit 1a9cc18260b68b149476adb6f39e37ab47d3d21f)
| * diff: fix OOM on AIX when finding similar deltas in empty diffPatrick Steinhardt2018-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function `git_diff_find_similar` keeps a function of cache similarity metrics signatures, whose size depends on the number of deltas passed in via the `diff` parameter. In case where the diff is empty and thus doesn't have any deltas at all, we may end up allocating this cache via a call to `git__calloc(0, sizeof(void *))`. At least on AIX, allocating 0 bytes will result in a `NULL` pointer being returned, which causes us to erroneously return an OOM error. Fix this situation by simply returning early in case where we are being passed an empty diff, as we cannot find any similarities in that case anyway. (cherry picked from commit c65568d8c8c1bf4920393190e862819cd263f439)
| * Fix the test and comment.Nelson Elhage2018-10-261-2/+20
| | | | | | | | (cherry picked from commit 6698e0562d0f782903f28c224c879da7c2abf674)
| * Write a test.Nelson Elhage2018-10-262-0/+16
| | | | | | | | (cherry picked from commit f140950066cf2989912e18ad92ec088f624b8bf2)
| * Add a commentNelson Elhage2018-10-261-0/+4
| | | | | | | | (cherry picked from commit ec76a1aa43321db2451e747d7a4408e780991c4a)
| * Don't error on missing section, just continueNelson Elhage2018-10-261-4/+4
| | | | | | | | (cherry picked from commit 019409be004fb73071415750e98db03d33fada47)
| * config_file: Don't crash on options without a sectionNelson Elhage2018-10-261-0/+4
| | | | | | | | (cherry picked from commit c4d7fa951acd066fd80d83954dd6082c1c7e9e1e)
| * parse: Do not initialize the content in context to NULLJulian Ganz2018-10-261-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | String operations in libgit2 are supposed to never receive `NULL`, e.g. they are not `NULL`-save. In the case of `git__linenlen()`, invocation with `NULL` leads to undefined behavior. In a `git_parse_ctx` however, the `content` field used in these operations was initialized to `NULL` if the `git_parse_ctx_init()` was called with `NULL` for `content` or `0` for `content_len`. For the latter case, the initialization function even contained some logic for initializing `content` with `NULL`. This commit mitigates triggering undefined behavior by rewriting the logic. Now `content` is always initialized to a non-null buffer. Instead of a null buffer, an empty string is used for denoting an empty buffer. (cherry picked from commit d1bfe614aa20a0bdaf76c6d418176320ab11baf4)
| * tree: rename from_tree to validate and clarify the tree in the testCarlos Martín Nieto2018-10-262-6/+7
| | | | | | | | (cherry picked from commit f00db9ed67423b04976f8d20b0de2ee1fb7c3993)
| * tree: accept null ids in existing trees when updatingCarlos Martín Nieto2018-10-263-6/+23
| | | | | | | | | | | | | | | | | | | | | | When we add entries to a treebuilder we validate them. But we validate even those that we're adding because they exist in the base tree. This disables using the normal mechanisms on these trees, even to fix them. Keep track of whether the entry we're appending comes from an existing tree and bypass the name and id validation if it's from existing data. (cherry picked from commit 2dff7e282da77f6b791e843ec267d9ddecabc187)
| * patch_parse: populate line numbers while parsing diffsEtienne Samson2018-10-262-0/+78
| | | | | | | | (cherry picked from commit f9e28026753f7b6c871a160ad584b2dc2639d30f)
| * worktree: a worktree can be made from a bare repositoryEtienne Samson2018-10-262-1/+21
| |
| * repository: being a worktree means we're not really bareEtienne Samson2018-10-261-3/+7
|/ | | | | | | We were previously conflating any error into GIT_ENOTFOUND, which might or might not be correct. This fixes the code so a config error is bubbled up, as well as preserving the semantics in the face of worktree-repositories
* Merge pull request #4866 from pks-t/pks/v0.27.6-securityv0.27.6Patrick Steinhardt2018-10-2648-455/+1204
|\ | | | | Release v0.27.6
| * version: bump to v0.27.6Patrick Steinhardt2018-10-261-2/+2
| |
| * CHANGELOG: update changelog for v0.27.6Patrick Steinhardt2018-10-261-0/+48
| |
| * commit: fix reading out of bounds when parsing encodingPatrick Steinhardt2018-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The commit message encoding is currently being parsed by the `git__prefixcmp` function. As this function does not accept a buffer length, it will happily skip over a buffer's end if it is not `NUL` terminated. Fix the issue by using `git__prefixncmp` instead. Add a test that verifies that we are unable to parse the encoding field if it's cut off by the supplied buffer length. (cherry picked from commit 7655b2d89e8275853d9921dd903dcdad9b3d4a7b)
| * tag: fix out of bounds read when searching for tag messagePatrick Steinhardt2018-10-261-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When parsing tags, we skip all unknown fields that appear before the tag message. This skipping is done by using a plain `strstr(buffer, "\n\n")` to search for the two newlines that separate tag fields from tag message. As it is not possible to supply a buffer length to `strstr`, this call may skip over the buffer's end and thus result in an out of bounds read. As `strstr` may return a pointer that is out of bounds, the following computation of `buffer_end - buffer` will overflow and result in an allocation of an invalid length. Fix the issue by using `git__memmem` instead. Add a test that verifies parsing the tag fails not due to the allocation failure but due to the tag having no message. (cherry picked from commit ee11d47e3d907b66eeff99e0ba1e1c71e05164b7)
| * util: provide `git__memmem` functionPatrick Steinhardt2018-10-263-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, neither the `memmem` nor the `strnstr` functions are part of any C standard but are merely extensions of C that are implemented by e.g. glibc. Thus, there is no standardized way to search for a string in a block of memory with a limited size, and using `strstr` is to be considered unsafe in case where the buffer has not been sanitized. In fact, there are some uses of `strstr` in exactly that unsafe way in our codebase. Provide a new function `git__memmem` that implements the `memmem` semantics. That is in a given haystack of `n` bytes, search for the occurrence of a byte sequence of `m` bytes and return a pointer to the first occurrence. The implementation chosen is the "Not So Naive" algorithm from [1]. It was chosen as the implementation is comparably simple while still being reasonably efficient in most cases. Preprocessing happens in constant time and space, searching has a time complexity of O(n*m) with a slightly sub-linear average case. [1]: http://www-igm.univ-mlv.fr/~lecroq/string/ (cherry picked from commit 83e8a6b36acc67f2702cbbc7d4e334c7f7737719)
| * util: fix out of bounds read in error messagePatrick Steinhardt2018-10-262-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an integer that is parsed with `git__strntol32` is too big to fit into an int32, we will generate an error message that includes the actual string that failed to parse. This does not acknowledge the fact that the string may either not be NUL terminated or alternative include additional characters after the number that is to be parsed. We may thus end up printing characters into the buffer that aren't the number or, worse, read out of bounds. Fix the issue by utilizing the `endptr` that was set by `git__strntol64`. This pointer is guaranteed to be set to the first character following the number, and we can thus use it to compute the width of the number that shall be printed. Create a test to verify that we correctly truncate the number. (cherry picked from commit ea19efc19fa683d632af3e172868bc4350724813)
| * util: avoid signed integer overflows in `git__strntol64`Patrick Steinhardt2018-10-261-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While `git__strntol64` tries to detect integer overflows when doing the necessary arithmetics to come up with the final result, it does the detection only after the fact. This check thus relies on undefined behavior of signed integer overflows. Fix this by instead checking up-front whether the multiplications or additions will overflow. Note that a detected overflow will not cause us to abort parsing the current sequence of digits. In the case of an overflow, previous behavior was to still set up the end pointer correctly to point to the first character immediately after the currently parsed number. We do not want to change this now as code may rely on the end pointer being set up correctly even if the parsed number is too big to be represented as 64 bit integer. (cherry picked from commit b09c1c7b636c4112e247adc24245c65f3f9478d0)
| * tests: core::strtol: test for some more edge-casesPatrick Steinhardt2018-10-261-0/+31
| | | | | | | | | | | | | | | | | | Some edge cases were currently completely untested, e.g. parsing numbers greater than INT64_{MIN,MAX}, truncating buffers by length and invalid characters. Add tests to verify that the system under test performs as expected. (cherry picked from commit 39087ab8ef77004c9f3b8984c38a834a6cb238bc)
| * util: remove `git__strtol32`Patrick Steinhardt2018-10-263-19/+19
| | | | | | | | | | | | | | | | | | The function `git__strtol32` can easily be misused when untrusted data is passed to it that may not have been sanitized with trailing `NUL` bytes. As all usages of this function have now been removed, we can remove this function altogether to avoid future misuse of it. (cherry picked from commit 8d7fa88a9d5011b653035497b0f523e0f177b6a6)
| * global: replace remaining use of `git__strtol32`Patrick Steinhardt2018-10-265-6/+8
| | | | | | | | | | | | | | | | | | Replace remaining uses of the `git__strtol32` function. While these uses are all safe as the strings were either sanitized or from a trusted source, we want to remove `git__strtol32` altogether to avoid future misuse. (cherry picked from commit 2613fbb26a3e1a34dda8a5d198c108626cfd6cc3)
| * tree-cache: avoid out-of-bound reads when parsing treesPatrick Steinhardt2018-10-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | We use the `git__strtol32` function to parse the child and entry count of treecaches from the index, which do not accept a buffer length. As the buffer that is being passed in is untrusted data and may thus be malformed and may not contain a terminating `NUL` byte, we can overrun the buffer and thus perform an out-of-bounds read. Fix the issue by uzing `git__strntol32` instead. (cherry picked from commit 21652ee9de439e042cc2e69b208aa2ef8ce31147)
| * util: remove unsafe `git__strtol64` functionPatrick Steinhardt2018-10-263-29/+16
| | | | | | | | | | | | | | | | | | | | The function `git__strtol64` does not take a maximum buffer length as parameter. This has led to some unsafe usages of this function, and as such we may consider it as being unsafe to use. As we have now eradicated all usages of this function, let's remove it completely to avoid future misuse. (cherry picked from commit 68deb2cc80ef19bf3a1915c26b5308b283a6d69a)
| * config: remove last instance of `git__strntol64`Patrick Steinhardt2018-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | When parsing integers from configuration values, we use `git__strtol64`. This is fine to do, as we always sanitize values and can thus be sure that they'll have a terminating `NUL` byte. But as this is the last call-site of `git__strtol64`, let's just pass in the length explicitly by calling `strlen` on the value to be able to remove `git__strtol64` altogether. (cherry picked from commit 1a2efd10bde66f798375e2f47ba57ef00ad5c193)
View Lorry Controller Status