|
a6d833a2
|
2017-01-13T17:05:58
|
|
Merge pull request #4049 from libgit2/ethomson/error_msgs
giterr_set: consistent error messages
|
|
2fdef641
|
2016-11-15T11:44:51
|
|
smart_pkt: treat empty packet lines as error
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.
|
|
|
66e3774d
|
2016-11-15T11:36:27
|
|
smart_pkt: verify packet length exceeds PKT_LEN_SIZE
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`.
|
|
909d5494
|
2016-12-29T12:25:15
|
|
giterr_set: consistent error messages
Error messages should be sentence fragments, and therefore:
1. Should not begin with a capital letter,
2. Should not conclude with punctuation, and
3. Should not end a sentence and begin a new one
|
|
|
7d02019a
|
2016-06-06T12:59:17
|
|
transports: smart: fix potential invalid memory dereferences
When we receive a packet of exactly four bytes encoding its
length as those four bytes it can be treated as an empty line.
While it is not really specified how those empty lines should be
treated, we currently ignore them and do not return an error when
trying to parse it but simply advance the data pointer.
Callers invoking `git_pkt_parse_line` are currently not prepared
to handle this case as they do not explicitly check this case.
While they could always reset the passed out-pointer to `NULL`
before calling `git_pkt_parse_line` and determine if the pointer
has been set afterwards, it makes more sense to update
`git_pkt_parse_line` to set the out-pointer to `NULL` itself when
it encounters such an empty packet. Like this it is guaranteed
that there will be no invalid memory references to free'd
pointers.
As such, the issue has been fixed such that `git_pkt_parse_line`
always sets the packet out pointer to `NULL` when an empty packet
has been received and callers check for this condition, skipping
such packets.
|
|
|
003c5e46
|
2016-02-22T15:52:49
|
|
transports: smart_pkt: fix memory leaks on error paths
|
|
|
6e2a3755
|
2016-02-23T11:45:43
|
|
smart_pkt: check buffer with GITERR_CHECK_ALLOC_BUF
|
|
|
b0f7512f
|
2016-02-15T11:46:10
|
|
transports: smart_pkt: fix memory leaks
|
|
2d1d2bb5
|
2015-08-05T18:50:25
|
|
Include the 4 characters not recognised as hex-number when setting error in parse_len
|
|
768f8be3
|
2015-06-30T19:00:41
|
|
Fix #3094 - improve use of portable size_t/ssize_t format specifiers.
The header src/cc-compat.h defines portable format specifiers PRIuZ, PRIdZ, and PRIxZ. The original report highlighted the need to use these specifiers in examples/network/fetch.c. For this commit, I checked all C source and header files not in deps/ and transitioned to the appropriate format specifier where appropriate.
|
|
f1453c59
|
2015-02-12T12:19:37
|
|
Make our overflow check look more like gcc/clang's
Make our overflow checking look more like gcc and clang's, so that
we can substitute it out with the compiler instrinsics on platforms
that support it. This means dropping the ability to pass `NULL` as
an out parameter.
As a result, the macros also get updated to reflect this as well.
|
|
|
ec3b4d35
|
2015-02-11T11:20:05
|
|
Use `size_t` to hold size of arrays
Use `size_t` to hold the size of arrays to ease overflow checking,
lest we check for overflow of a `size_t` then promptly truncate
by packing the length into a smaller type.
|
|
|
4aa664ae
|
2015-02-10T23:55:07
|
|
git_buf_grow_by: increase buf asize incrementally
Introduce `git_buf_grow_by` to incrementally increase the size of a
`git_buf`, performing an overflow calculation on the growth.
|
|
|
392702ee
|
2015-02-09T23:41:13
|
|
allocations: test for overflow of requested size
Introduce some helper macros to test integer overflow from arithmetic
and set error message appropriately.
|
|
306475eb
|
2014-05-20T09:55:26
|
|
remote: expose the remote's symref mappings
Add a symref_target field to git_remote_head to expose the symref
mappings to the user.
|
|
98020d3a
|
2014-04-21T10:55:37
|
|
Rename progress callback to sideband_progress
|
|
|
2f8c481c
|
2013-10-08T16:22:21
|
|
protocol: basic support for multi_ack_detailed
This tells the server that we speak it, but we don't make use of its
extra information to determine if there's a better place to stop
negotiating.
In a somewhat-related change, reorder the capabilities so we ask for
them in the same order as git does.
Also take this opportunity to factor out a fairly-indented portion of
the negotiation logic.
|
|
|
b4342b11
|
2013-10-04T10:27:45
|
|
net: advertise our support for fixing thin packs
|
|
b8c32580
|
2013-03-12T15:19:32
|
|
Advertise and support side-band-64k when calling receive-pack
|
|
359fc2d2
|
2013-01-08T17:07:25
|
|
update copyrights
|
|
|
6762fe08
|
2012-11-29T08:29:26
|
|
Remove casts of return values of type void *
|
|
|
613d5eb9
|
2012-11-28T11:42:37
|
|
Push! By schu, phkelley, and congyiwu, et al
|
|
|
41fb1ca0
|
2012-10-29T13:41:14
|
|
Reorganize transport architecture (squashed 3)
|