|
4947216f
|
2019-01-21T11:11:27
|
|
git transport: only write INT_MAX bytes
The transport code returns an `int` with the number of bytes written;
thus only attempt to write at most `INT_MAX`.
|
|
bff7aed2
|
2019-01-24T16:44:04
|
|
Don't use deprecated constants
Follow up for PR #4917.
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
|
|
f673e232
|
2018-12-27T13:47:34
|
|
git_error: use new names in internal APIs and usage
Move to the `git_error` name in the internal API for error-related
functions.
|
|
|
1758636b
|
2019-01-19T01:38:34
|
|
Merge pull request #4939 from libgit2/ethomson/git_ref
Move `git_ref_t` to `git_reference_t`
|
|
|
abe23675
|
2019-01-17T20:09:05
|
|
Merge pull request #4925 from lhchavez/fix-a-bunch-of-warnings
Fix a bunch of warnings
|
|
|
ed8cfbf0
|
2019-01-17T00:32:31
|
|
references: use new names in internal usage
Update internal usage to use the `git_reference` names for constants.
|
|
35d86c77
|
2019-01-14T10:14:36
|
|
proxy: fix crash on remote connection with GIT_PROXY_AUTO but no proxy is detected
|
|
321d19c1
|
2019-01-06T08:36:06
|
|
Windows is hard.
|
|
|
7b453e7e
|
2019-01-05T22:12:48
|
|
Fix a bunch of warnings
This change fixes a bunch of warnings that were discovered by compiling
with `clang -target=i386-pc-linux-gnu`. It turned out that the
intrinsics were not necessarily being used in all platforms! Especially
in GCC, since it does not support __has_builtin.
Some more warnings were gleaned from the Windows build, but I stopped
when I saw that some third-party dependencies (e.g. zlib) have warnings
of their own, so we might never be able to enable -Werror there.
|
|
|
168fe39b
|
2018-11-28T14:26:57
|
|
object_type: use new enumeration names
Use the new object_type enumeration names within the codebase.
|
|
|
30ac46aa
|
2018-11-28T10:12:43
|
|
http: reset replay_count upon connection
Reset the replay_count upon a successful connection. It's possible that
we could encounter a situation where we connect successfully but need to
replay a request - for example, a connection and initial request
succeeds without authentication but a subsequent call does require
authentication. Reset the replay count upon any successful request to
afford subsequent replays room to manuever.
|
|
|
52478d7d
|
2018-11-18T19:54:49
|
|
http: don't allow SSL connections to a proxy
Temporarily disallow SSL connections to a proxy until we can understand
the valgrind warnings when tunneling OpenSSL over OpenSSL.
|
|
|
41f620d9
|
2018-11-18T19:10:50
|
|
http: only load proxy configuration during connection
Only load the proxy configuration during connection; we need this data
when we're going to connect to the server, however we may mutate it
after connection (connecting through a CONNECT proxy means that we
should send requests like normal). If we reload the proxy configuration
but do not actually reconnect (because we're in a keep-alive session)
then we will reload the proxy configuration that we should have mutated.
Thus, only load the proxy configuration when we know that we're going to
reconnect.
|
|
|
0467606f
|
2018-11-18T11:00:11
|
|
http: disallow repeated headers from servers
Don't allow servers to send us multiple Content-Type, Content-Length
or Location headers.
|
|
|
21142c5a
|
2018-10-29T10:04:48
|
|
http: remove cURL
We previously used cURL to support HTTP proxies. Now that we've added
this support natively, we can remove the curl dependency.
|
|
|
5d4e1e04
|
2018-10-28T21:27:56
|
|
http: use CONNECT to talk to proxies
Natively support HTTPS connections through proxies by speaking CONNECT
to the proxy and then adding a TLS connection on top of the socket.
|
|
|
43b592ac
|
2018-10-25T08:49:01
|
|
tls: introduce a wrap function
Introduce `git_tls_stream_wrap` which will take an existing `stream`
with an already connected socket and begin speaking TLS on top of it.
This is useful if you've built a connection to a proxy server and you
wish to begin CONNECT over it to tunnel a TLS connection.
Also update the pluggable TLS stream layer so that it can accept a
registration structure that provides an `init` and `wrap` function,
instead of a single initialization function.
|
|
|
b2ed778a
|
2018-11-18T22:20:10
|
|
http transport: reset error message on cert failure
Store the error message from the underlying TLS library before calling
the certificate callback. If it refuses to act (demonstrated by
returning GIT_PASSTHROUGH) then restore the error message. Otherwise,
if the callback does not set an error message, set a sensible default
that implicates the callback itself.
|
|
|
2ce2315c
|
2018-10-22T17:33:45
|
|
http transport: support cert check for proxies
Refactor certificate checking so that it can easily be called for
proxies or the remote server.
|
|
|
74c6e08e
|
2018-10-22T14:56:53
|
|
http transport: provide proxy credentials
|
|
|
496da38c
|
2018-10-22T12:48:45
|
|
http transport: refactor storage
Create a simple data structure that contains information about the
server being connected to, whether that's the actual remote endpoint
(git server) or an intermediate proxy. This allows for organization of
streams, authentication state, etc.
|
|
|
6af8572c
|
2018-10-22T11:29:01
|
|
http transport: cap number of authentication replays
Put a limit on the number of authentication replays in the HTTP
transport. Standardize on 7 replays for authentication or redirects,
which matches the behavior of the WinHTTP transport.
|
|
|
22654812
|
2018-10-22T11:24:05
|
|
http transport: prompt for proxy credentials
Teach the HTTP transport how to prompt for proxy credentials.
|
|
|
0328eef6
|
2018-10-22T11:14:06
|
|
http transport: further refactor credential handling
Prepare credential handling to understand both git server and proxy
server authentication.
|
|
|
32cb56ce
|
2018-10-22T10:16:54
|
|
http transport: refactor credential handling
Factor credential handling into its own function. Additionally, add
safety checks to ensure that we are in a valid state - that we have
received a valid challenge from the server and that we have
configuration to respond to that challenge.
|
|
|
e6e399ab
|
2018-10-22T09:49:54
|
|
http transport: use HTTP proxies when requested
The HTTP transport should understand how to apply proxies when
configured with `GIT_PROXY_SPECIFIED` and `GIT_PROXY_SPECIFIED`.
When a proxy is configured, the HTTP transport will now connect
to the proxy (instead of directly to the git server), and will
request the properly-formed URL of the git server endpoint.
|
|
|
e6f1931a
|
2018-10-22T00:09:24
|
|
http: rename http subtransport's `io` to `gitserver_stream`
Rename `http_subtransport->io` to `http_subtransport->gitserver_stream`
to clarify its use, especially as we might have additional streams (eg
for a proxy) in the future.
|
|
|
c07ff4cb
|
2018-10-21T14:17:06
|
|
http: rename `connection_data` -> `gitserver_data`
Rename the `connection_data` struct member to `gitserver_data`, to
disambiguate future `connection_data`s that apply to the proxy, not the
final server endpoint.
|
|
|
ed72465e
|
2018-10-13T19:16:54
|
|
proxy: propagate proxy configuration errors
|
|
c97d302d
|
2018-11-28T13:45:41
|
|
Merge pull request #4879 from libgit2/ethomson/defer_cert_cred_cb
Allow certificate and credential callbacks to decline to act
|
|
|
a2e6e0ea
|
2018-11-06T14:15:43
|
|
transport: allow cred/cert callbacks to return GIT_PASSTHROUGH
Allow credential and certificate checking callbacks to return
GIT_PASSTHROUGH, indicating that they do not want to act.
Introduce this to support in both the http and ssh callbacks.
Additionally, enable the same mechanism for certificate validation.
This is most useful to disambiguate any meaning in the publicly exposed
credential and certificate functions (`git_transport_smart_credentials`
and `git_transport_smart_certificate_check`) but it may be more
generally useful for callers to be able to defer back to libgit2.
|
|
|
4ef2b889
|
2018-11-18T22:56:28
|
|
Merge pull request #4882 from kc8apf/include_port_in_host_header
transport/http: Include non-default ports in Host header
|
|
|
8ee10098
|
2018-11-06T13:10:30
|
|
transport: see if cert/cred callbacks exist before calling them
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
(GIT_PASSTHROUGH) if there is no callback configured instead of crashing.
|
|
83b35181
|
2018-10-19T10:54:38
|
|
transport/http: Include non-default ports in Host header
When the port is omitted, the server assumes the default port for the
service is used (see
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host). In
cases where the client provided a non-default port, it should be passed
along.
This hasn't been an issue so far as the git protocol doesn't include
server-generated URIs. I encountered this when implementing Rust
registry support for Sonatype Nexus. Rust's registry uses a git
repository for the package index. Clients look at a file in the root of
the package index to find the base URL for downloading the packages.
Sonatype Nexus looks at the incoming HTTP request (Host header and URL)
to determine the client-facing URL base as it may be running behind a
load balancer or reverse proxy. This client-facing URL base is then used
to construct the package download base URL. When libgit2 fetches the
index from Nexus on a non-default port, Nexus trusts the incorrect Host
header and generates an incorrect package download base URL.
|
|
|
9ad96367
|
2018-11-07T15:31:21
|
|
smart transport: only clear url on hard reset
After creating a transport for a server, we expect to be able to call
`connect`, then invoke subsequent `action` calls. We provide the URL to
these `action` calls, although our built-in transports happen to ignore
it since they've already parsed it into an internal format that they
intend to use (`gitno_connection_data`).
In ca2eb4608243162a13c427e74526b6422d5a6659, we began clearing the URL
field after a connection, meaning that subsequent calls to transport
`action` callbacks would get a NULL URL, which went undetected since the
builtin transports ignore the URL when they're already connected
(instead of re-parsing it into an internal format).
Downstream custom transport implementations (eg, LibGit2Sharp) did
notice this change, however.
Since `reset_stream` is called even when we're not closing the
subtransport, update to only clear the URL when we're closing the
subtransport. This ensures that `action` calls will get the correct URL
information even after a connection.
|
|
|
2613fbb2
|
2018-10-18T11:58:14
|
|
global: replace remaining use of `git__strtol32`
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.
|
|
9b6e4081
|
2018-10-15T17:08:38
|
|
Merge commit 'afd10f0' (Follow 308 redirects)
|
|
afd10f0b
|
2018-10-13T09:31:20
|
|
Follow 308 redirects (as used by GitLab)
|
|
475db39b
|
2018-10-06T12:58:06
|
|
ignore unsupported http authentication schemes
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.
|
|
|
1bc5b05c
|
2018-10-03T16:17:21
|
|
smart_pkt: do not accept callers passing in no line length
Right now, we simply ignore the `linelen` parameter of
`git_pkt_parse_line` in case the caller passed in zero. But in fact, we
never want to assume anything about the provided buffer length and
always want the caller to pass in the available number of bytes.
And in fact, checking all the callers, one can see that the funciton is
never being called in case where the buffer length is zero, and thus we
are safe to remove this check.
|
|
|
c05790a8
|
2018-08-09T11:16:15
|
|
smart_pkt: return parsed length via out-parameter
The `parse_len` function currently directly returns the parsed length of
a packet line or an error code in case there was an error. Instead,
convert this to our usual style of using the return value as error code
only and returning the actual value via an out-parameter. Thus, we can
now convert the output parameter to an unsigned type, as the size of a
packet cannot ever be negative.
While at it, we also move the check whether the input buffer is long
enough into `parse_len` itself. We don't really want to pass around
potentially non-NUL-terminated buffers to functions without also passing
along the length, as this is dangerous in the unlikely case where other
callers for that function get added. Note that we need to make sure
though to not mess with `GIT_EBUFS` error codes, as these indicate not
an error to the caller but that he needs to fetch more data.
|
|
|
0b3dfbf4
|
2018-08-09T11:13:59
|
|
smart_pkt: reorder and rename parameters of `git_pkt_parse_line`
The parameters of the `git_pkt_parse_line` function are quite confusing.
First, there is no real indicator what the `out` parameter is actually
all about, and it's not really clear what the `bufflen` parameter refers
to. Reorder and rename the parameters to make this more obvious.
|
|
|
5fabaca8
|
2018-08-09T11:04:42
|
|
smart_pkt: fix buffer overflow when parsing "unpack" packets
When checking whether an "unpack" packet returned the "ok" status or
not, we use a call to `git__prefixcmp`. In case where the passed line
isn't properly NUL terminated, though, this may overrun the line buffer.
Fix this by using `git__prefixncmp` instead.
|
|
|
b5ba7af2
|
2018-08-09T11:03:37
|
|
smart_pkt: fix "ng" parser accepting non-space character
When parsing "ng" packets, we blindly assume that the character
immediately following the "ng" prefix is a space and skip it. As the
calling function doesn't make sure that this is the case, we can thus
end up blindly accepting an invalid packet line.
Fix the issue by using `git__prefixncmp`, checking whether the line
starts with "ng ".
|
|
|
a9f1ca09
|
2018-08-09T11:01:00
|
|
smart_pkt: fix buffer overflow when parsing "ok" packets
There are two different buffer overflows present when parsing "ok"
packets. First, we never verify whether the line already ends after
"ok", but directly go ahead and also try to skip the expected space
after "ok". Second, we then go ahead and use `strchr` to scan for the
terminating newline character. But in case where the line isn't
terminated correctly, this can overflow the line buffer.
Fix the issues by using `git__prefixncmp` to check for the "ok " prefix
and only checking for a trailing '\n' instead of using `memchr`. This
also fixes the issue of us always requiring a trailing '\n'.
Reported by oss-fuzz, issue 9749:
Crash Type: Heap-buffer-overflow READ {*}
Crash Address: 0x6310000389c0
Crash State:
ok_pkt
git_pkt_parse_line
git_smart__store_refs
Sanitizer: address (ASAN)
|
|
|
bc349045
|
2018-08-09T10:38:10
|
|
smart_pkt: fix buffer overflow when parsing "ACK" packets
We are being quite lenient when parsing "ACK" packets. First, we didn't
correctly verify that we're not overrunning the provided buffer length,
which we fix here by using `git__prefixncmp` instead of
`git__prefixcmp`. Second, we do not verify that the actual contents make
any sense at all, as we simply ignore errors when parsing the ACKs OID
and any unknown status strings. This may result in a parsed packet
structure with invalid contents, which is being silently passed to the
caller. This is being fixed by performing proper input validation and
checking of return codes.
|
|
|
5edcf5d1
|
2018-08-09T10:57:06
|
|
smart_pkt: adjust style of "ref" packet parsing function
While the function parsing ref packets doesn't have any immediately
obvious buffer overflows, it's style is different to all the other
parsing functions. Instead of checking buffer length while we go, it
does a check up-front. This causes the code to seem a lot more magical
than it really is due to some magic constants. Refactor the function to
instead make use of the style of other packet parser and verify buffer
lengths as we go.
|
|
|
786426ea
|
2018-08-09T10:46:58
|
|
smart_pkt: check whether error packets are prefixed with "ERR "
In the `git_pkt_parse_line` function, we determine what kind of packet
a given packet line contains by simply checking for the prefix of that
line. Except for "ERR" packets, we always only check for the immediate
identifier without the trailing space (e.g. we check for an "ACK"
prefix, not for "ACK "). But for "ERR" packets, we do in fact include
the trailing space in our check. This is not really much of a problem at
all, but it is inconsistent with all the other packet types and thus
causes confusion when the `err_pkt` function just immediately skips the
space without checking whether it overflows the line buffer.
Adjust the check in `git_pkt_parse_line` to not include the trailing
space and instead move it into `err_pkt` for consistency.
|
|
|
40fd84cc
|
2018-08-09T10:46:26
|
|
smart_pkt: explicitly avoid integer overflows when parsing packets
When parsing data, progress or error packets, we need to copy the
contents of the rest of the current packet line into the flex-array of
the parsed packet. To keep track of this array's length, we then assign
the remaining length of the packet line to the structure. We do have a
mismatch of types here, as the structure's `len` field is a signed
integer, while the length that we are assigning has type `size_t`.
On nearly all platforms, this shouldn't pose any problems at all. The
line length can at most be 16^4, as the line's length is being encoded
by exactly four hex digits. But on a platforms with 16 bit integers,
this assignment could cause an overflow. While such platforms will
probably only exist in the embedded ecosystem, we still want to avoid
this potential overflow. Thus, we now simply change the structure's
`len` member to be of type `size_t` to avoid any integer promotion.
|
|
|
4a5804c9
|
2018-08-09T10:36:44
|
|
smart_pkt: honor line length when determining packet type
When we parse the packet type of an incoming packet line, we do not
verify that we don't overflow the provided line buffer. Fix this by
using `git__prefixncmp` instead and passing in `len`. As we have
previously already verified that `len <= linelen`, we thus won't ever
overflow the provided buffer length.
|
|
|
9a193102
|
2018-08-24T11:01:39
|
|
Merge pull request #4774 from tiennou/fix/clang-analyzer
Coverity flavored clang analyzer fixes
|
|
1c949ce1
|
2018-08-21T02:11:32
|
|
transport/http: do not return success if we failed to get a scheme
Otherwise we return a NULL context, which will get dereferenced in
apply_credentials.
|
|
50dd7fea
|
2018-08-11T13:06:14
|
|
Fix 'invalid packet line' for ng packets containing errors
|
|
|
9ada072e
|
2018-08-06T13:31:23
|
|
Merge pull request #4758 from pks-t/pks/smart-pkt-oob-read
smart_pkt: fix potential OOB-read when processing ng packet
|
|
|
ba55592f
|
2018-08-02T20:34:56
|
|
Merge pull request #4743 from Agent00Log/dev/winbugfixes
Windows: default credentials / fallback credential handling
|
|
ccbffbae
|
2018-07-30T13:39:21
|
|
Only unitialize if the call to CoInitializeEx was successful
|
|
|
b00a09b0
|
2018-07-27T20:14:27
|
|
Merge pull request #4731 from libgit2/ethomson/wintls_fix
winhttp: retry erroneously failing requests
|
|
|
8c21cb5c
|
2018-07-26T09:52:32
|
|
Fix fallback credentials: The call to CoInitializeEx fails if it was previously been set to a different mode.
|
|
|
c9dc30ff
|
2018-07-26T09:52:21
|
|
Fix default credentials: The WinHttpSetCredentials auth scheme must only be one of the supported schemes.
|
|
|
ca2eb460
|
2018-07-20T21:50:58
|
|
smart subtransport: free url when resetting stream
Free the url field when resetting the stream to avoid leaking it.
|
|
|
dc371e3c
|
2018-07-20T08:20:48
|
|
winhttp: retry erroneously failing requests
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.
|
|
|
0652abaa
|
2018-07-20T12:56:49
|
|
Merge pull request #4702 from tiennou/fix/coverity
Assorted Coverity fixes
|
|
|
19bed3e2
|
2018-07-19T13:00:42
|
|
smart_pkt: fix potential OOB-read when processing ng packet
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
|
|
|
fa401a32
|
2018-07-19T08:20:04
|
|
Merge pull request #4704 from nelhage/no-pkt-pack
Remove GIT_PKT_PACK entirely
|
|
388149f5
|
2018-07-15T17:25:26
|
|
No need for this placeholder.
|
|
|
9994cd3f
|
2018-06-25T11:56:52
|
|
treewide: remove use of C++ style comments
C++ style comment ("//") are not specified by the ISO C90 standard and
thus do not conform to it. While libgit2 aims to conform to C90, we did
not enforce it until now, which is why quite a lot of these
non-conforming comments have snuck into our codebase. Do a tree-wide
conversion of all C++ style comments to the supported C style comments
to allow us enforcing strict C90 compliance in a later commit.
|
|
|
6ae6491e
|
2018-07-06T22:24:16
|
|
smart: don't dereference a NULL pkt pointer
By clarifying what detect_caps returns on empty/missing packet, we can
be sure there are actually refs to process. The old code could blindly
dereference `first`, which might have been NULL.
Reported by Coverity, CID 1393614
|
|
|
68c7480a
|
2018-07-06T20:21:25
|
|
smart: clarify error handling in git_smart__connect
|
|
|
a73b7c2f
|
2018-06-29T16:54:06
|
|
This error case is now unneeded
|
|
|
b8408557
|
2018-06-29T16:53:23
|
|
Merge remote-tracking branch 'origin/master' into no-pkt-pack
|
|
|
af3088e4
|
2018-06-29T11:45:15
|
|
refspec: rename `git_refspec__free` to `git_refspec__dispose`
Since commit 630a67366 (refspec: add public parsing api, 2018-02-07), we
now have two functions `git_refspec_free` and `git_refspec__free`. The
difference is that the first one will free the structure itself, while
the second one will only free the structure's contents. Use our new
`dispose` naming pattern for the latter function to help avoid
confusion.
|
|
|
895a668e
|
2018-06-28T05:27:36
|
|
Small style tweak, and set an error
|
|
|
12232a5e
|
2018-06-27T17:19:37
|
|
Merge pull request #4698 from nelhage/fix-leaks
Fix assorted leaks found via fuzzing
|
|
|
5dd34702
|
2018-06-26T09:56:43
|
|
Merge branch 'nelhage/smart-no-pack'
|
|
|
9286e413
|
2018-06-26T09:56:06
|
|
smart protocol: correct error message capitalization
|
|
|
90cf8607
|
2018-06-26T02:32:50
|
|
Remove GIT_PKT_PACK entirely
|
|
|
3a547417
|
2018-06-25T15:38:29
|
|
git_pkt_free: Allow freeing NULL
|
|
|
e6cdd17c
|
2018-06-25T13:57:19
|
|
Merge pull request #4695 from nelhage/git_pkt-type-confusion
Fix type confusion in git_smart__connect
|
|
|
d58afb17
|
2018-06-24T22:28:37
|
|
git_smart__connect: free symrefs on error
|
|
|
cf335928
|
2018-06-24T22:22:40
|
|
git_smart__update_heads: free the old symref_target
|
|
|
e31c450b
|
2018-06-24T23:46:36
|
|
Fix another missing git_pkt_free
|
|
|
bf4c2c57
|
2018-06-24T21:56:51
|
|
wait_while_ack: use git_pkt_free
git__free is insufficient if the packet is a git_pkt_ref or another
type that requires freeing referenced structures.
|
|
|
437ee5a7
|
2018-06-24T19:47:08
|
|
Verify ref_pkt's are long enough
If the remote sends a too-short packet, we'll allow `len` to go
negative and eventually issue a malloc for <= 0 bytes on
```
pkt->head.name = git__malloc(alloclen);
```
|
|
|
0098d746
|
2018-06-24T06:51:31
|
|
Fix type confusion in git_smart__connect
Nothing verifies that t->refs[0] is a GIT_PKT_REF. A remote can send
another packet type, ultimately resulting in a type confusion in
`git_smart__detect_caps`
|
|
|
3eec73ae
|
2018-06-24T20:54:41
|
|
PACK packets are illegal while downloading refs
|
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
|
836ec316
|
2018-04-19T01:05:05
|
|
local: fix a leaking reference when iterating over a symref
Valgrind log :
==17702== 18 bytes in 1 blocks are indirectly lost in loss record 69 of 1,123
==17702== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17702== by 0x5FDBB49: strdup (strdup.c:42)
==17702== by 0x632B3E: git__strdup (util.h:106)
==17702== by 0x632D2C: git_reference__alloc_symbolic (refs.c:64)
==17702== by 0x62E0AF: loose_lookup (refdb_fs.c:408)
==17702== by 0x62E636: refdb_fs_backend__iterator_next (refdb_fs.c:565)
==17702== by 0x62CD8E: git_refdb_iterator_next (refdb.c:147)
==17702== by 0x6347F2: git_reference_next (refs.c:838)
==17702== by 0x6345CB: git_reference_foreach (refs.c:748)
==17702== by 0x66BE62: local_download_pack (local.c:579)
==17702== by 0x5DB48F: git_fetch_download_pack (fetch.c:148)
==17702== by 0x639028: git_remote_download (remote.c:932)
==17702== by 0x63919A: git_remote_fetch (remote.c:969)
==17702== by 0x4ABEDD: test_fetchhead_nonetwork__fetch_into_repo_with_symrefs (nonetwork.c:362)
==17702== by 0x4125D9: clar_run_test (clar.c:222)
==17702== by 0x41287C: clar_run_suite (clar.c:286)
==17702== by 0x412DDE: clar_test_run (clar.c:433)
==17702== by 0x4105E1: main (main.c:24)
|
|
|
e5f32e81
|
2018-04-17T00:08:20
|
|
Merge pull request #4514 from tiennou/fix/pkt-type-enum
Typedef git_pkt_type and clarify recv_pkt return type
|
|
|
17339cb3
|
2018-04-16T15:35:56
|
|
Merge pull request #4596 from pks-t/pks/ssh-disconnect
transports: ssh: disconnect session before freeing it
|
|
|
13a77274
|
2018-02-26T21:33:55
|
|
smart: typo
|
|
|
2cf9b84c
|
2018-04-11T19:13:42
|
|
smart: free the pkt when we fail to store it
|
|
|
32586d5e
|
2018-04-11T19:03:57
|
|
smart: separate error handling from pkt handling
|
|
|
01381149
|
2018-02-26T21:27:10
|
|
smart: make out arguments explicit on recv_pkt
|
|
|
08961c9d
|
2017-08-22T16:29:07
|
|
smart: typedef git_pkt_type and clarify recv_pkt return type
|
|
|
6c55fbf3
|
2018-04-06T10:39:16
|
|
transports: local: fix assert when fetching into repo with symrefs
When fetching into a repository which has symbolic references via the
"local" transport we run into an assert. The assert is being triggered
while we negotiate the packfile between the two repositories. When
hiding known revisions from the packbuilder revwalk, we unconditionally
hide all references of the local refdb. In case one of these references
is a symbolic reference, though, this means we're trying to hide a
`NULL` OID, which triggers the assert.
Fix the issue by only hiding OID references from the revwalk. Add a test
to catch this issue in the future.
|
|
|
874ce161
|
2018-03-27T15:03:15
|
|
transports: ssh: replace deprecated function `libssh2_session_startup`
The function `libssh2_session_startup` has been deprecated since libssh2
version 1.2.8 in favor of `libssh2_session_handshake` introduced in the
same version. libssh2 1.2.8 was released in April 2011, so it is already
seven years old. It is available in Debian Wheezy, Ubuntu Trusty and
CentOS 7.4, so the most important and conservative distros already have
it available. As such, it seems safe to just use the new function.
|
|
|
2785cc8e
|
2018-03-27T14:49:21
|
|
transports: ssh: disconnect session before freeing it
The function `ssh_stream_free` takes over the responsibility of closing
channels and streams just before freeing their memory, but it does not
do so for the session. In fact, we never disconnect the session
ourselves at all, as libssh2 will not do so itself upon freeing the
structure. Quoting the documentation of `libssh2_session_free`:
> Frees all resources associated with a session instance. Typically
> called after libssh2_session_disconnect_ex,
The missing disconnect probably stems from a misunderstanding what it
actually does. As we are already closing the TCP socket ourselves, the
assumption was that no additional disconnect is required. But calling
`libssh2_session_disconnect` will notify the server that we are cleanly
closing the connection, such that the server can free his own resources.
Add a call to `libssh2_session_disconnect` to fix that issue.
[1]: https://www.libssh2.org/libssh2_session_free.html
|
|
|
6f577906
|
2018-03-03T20:09:09
|
|
ssh urls: use `git_buf_decode_percent`
Use `git_buf_decode_percent` so that we can avoid allocating a temporary
buffer.
|
|
16210877
|
2018-02-28T12:59:47
|
|
Unescape repo before constructing ssh request
|
|
|
5ecb6220
|
2018-02-25T15:46:51
|
|
winhttp: enable TLS 1.2 on Windows 7 and earlier
Versions of Windows prior to Windows 8 do not enable TLS 1.2 by default,
though support may exist. Try to enable TLS 1.2 support explicitly on
connections.
This request may fail if the operating system does not have TLS 1.2
support - the initial release of Vista lacks TLS 1.2 support (though
it is available as a software update) and XP completely lacks TLS 1.2
support. If this request does fail, the HTTP context is still valid,
and still maintains the original protocol support. So we ignore the
failure from this operation.
|