| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The getline(3) function call is not part of ISO C and, most importantly,
it is not implemented on Microsoft Windows platforms. As our networking
example code makes use of getline, this breaks builds on MSVC and MinGW.
As this code wasn't built prior to the previous commit, this was never
noticed.
Fix the error by instead implementing a `readline` function, which
simply reads the password from stdin until it reads a newline
character.
|
| | |
|
| |
|
|
|
| |
Our build YAML is becoming unweildly and full of copy-pasta. Simplify
with templates.
|
| |
|
|
|
| |
Explicitly run from the build directory, not the source. (I was
mistaken about the default working directory for VSTS agents.)
|
| |
|
|
|
| |
Before resetting the url and username, ensure that we free them in case
they were set by environment variables.
|
| |
|
|
|
|
|
| |
Our CI test system invokes ctest with the name of the given tests it
wishes to invoke. ctest (with the `-R` flag) treats this name as a
regular expression. Provide anchors in the regular expression to avoid
matching additional tests in this search.
|
| |
|
|
| |
Free the url field when resetting the stream to avoid leaking it.
|
| |
|
|
| |
Don't just free the spec vector, also free the specs themselves.
|
| |
|
|
|
| |
Don't just free the push status structure, actually free the strings that were
strdup'd into the struct as well.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of trying to run coverity builds during the regular PR process,
run them during a regularly scheduled cron process. These only need to
run nightly, so it makes sense to bring them out of the PR process.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The leaks process is not good about handling children. Ensure that its
child is `nohup`ed so that the grandparent shell won't wait for it to
exit.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
On Linux (where we run valgrind) allocate a smaller buffer, but still an
insanely large size. This will cause malloc to fail but will not cause
valgrind to report a likely error with a negative-sized malloc.
Keep the original buffer size on non-Linux platforms: this is
well-tested on them and changing it may be problematic. On macOS, for
example, using the new size causes `malloc` to print a warning to
stderr.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Script to set up dependencies on a macOS build system.
|
| |
|
|
| |
Sets up a linux host to prepare for a build.
|
| |
|
|
| |
Refactor citest.sh to enable local testing by developers.
|
| | |
|
| |
|
|
| |
Add citest.ps1 PowerShell script to run the tests.
|
| | |
|
| |\
| |
| | |
Release v0.26.6
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OSS-fuzz has reported a potential out-of-bounds read when processing a
"ng" smart packet:
==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6310000249c0 at pc 0x000000493a92 bp 0x7ffddc882cd0 sp 0x7ffddc882480
READ of size 65529 at 0x6310000249c0 thread T0
SCARINESS: 26 (multi-byte-read-heap-buffer-overflow)
#0 0x493a91 in __interceptor_strchr.part.35 /src/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:673
#1 0x813960 in ng_pkt libgit2/src/transports/smart_pkt.c:320:14
#2 0x810f79 in git_pkt_parse_line libgit2/src/transports/smart_pkt.c:478:9
#3 0x82c3c9 in git_smart__store_refs libgit2/src/transports/smart_protocol.c:47:12
#4 0x6373a2 in git_smart__connect libgit2/src/transports/smart.c:251:15
#5 0x57688f in git_remote_connect libgit2/src/remote.c:708:15
#6 0x52e59b in LLVMFuzzerTestOneInput /src/download_refs_fuzzer.cc:145:9
#7 0x52ef3f in ExecuteFilesOnyByOne(int, char**) /src/libfuzzer/afl/afl_driver.cpp:301:5
#8 0x52f4ee in main /src/libfuzzer/afl/afl_driver.cpp:339:12
#9 0x7f6c910db82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
#10 0x41d518 in _start
When parsing an "ng" packet, we keep track of both the current position
as well as the remaining length of the packet itself. But instead of
taking care not to exceed the length, we pass the current pointer's
position to `strchr`, which will search for a certain character until
hitting NUL. It is thus possible to create a crafted packet which
doesn't contain a NUL byte to trigger an out-of-bounds read.
Fix the issue by instead using `memchr`, passing the remaining length as
restriction. Furthermore, verify that we actually have enough bytes left
to produce a match at all.
OSS-Fuzz-Issue: 9406
|
| |/
|
|
|
|
|
|
| |
Travis has upgraded the default Xcode images from 8.3 to 9.4 on 31st
July 2018, including an upgrade to macOS 10.13. Unfortunately, this
breaks our CI builds on our maintenance branches. As we do not want to
include mayor changes to fix the integration right now, we force use of
the old Xcode 8.3 images.
|
| |\
| |
| | |
Release v0.26.5
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When checking whether a delta base offset and length fit into the base
we have in memory already, we can trigger an overflow which breaks the
check. This would subsequently result in us reading memory from out of
bounds of the base.
The issue is easily fixed by checking for overflow when adding `off` and
`len`, thus guaranteeting that we are never indexing beyond `base_len`.
This corresponds to the git patch 8960844a7 (check patch_delta bounds
more carefully, 2006-04-07), which adds these overflow checks.
Reported-by: Riccardo Schirone <rschiron@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When computing the offset and length of the delta base, we repeatedly
increment the `delta` pointer without checking whether we have advanced
past its end already, which can thus result in an out-of-bounds read.
Fix this by repeatedly checking whether we have reached the end. Add a
test which would cause Valgrind to produce an error.
Reported-by: Riccardo Schirone <rschiron@redhat.com>
Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
|
