|
e181a649
|
2018-09-18T03:03:03
|
|
Merge pull request #4809 from libgit2/cmn/revwalk-sign-regression
Fix revwalk limiting regression
|
|
12a1790d
|
2018-09-17T14:49:46
|
|
revwalk: only check the first commit in the list for an earlier timestamp
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.
|
|
46f35127
|
2018-09-17T14:39:58
|
|
revwalk: use the max value for a signed integer
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.
|
|
44291868
|
2018-09-12T10:53:03
|
|
path validation: `char` is not signed by default.
ARM treats its `char` type as `unsigned type` by default; as a result,
testing a `char` value as being `< 0` is always false. This is a
warning on ARM, which is promoted to an error given our use of
`-Werror`.
Per ISO 9899:199, section "6.2.5 Types":
> The three types char, signed char, and unsigned char are collectively
> called the character types. The implementation shall define char to
> have the same range, representation, and behavior as either signed
> char or unsigned char.
>
...
> Irrespective of the choice made, char is a separate type from the other
> two and is not compatible with either.
|
|
55d354d8
|
2018-09-07T13:20:33
|
|
Merge pull request #4785 from tiennou/fix/cleanup-remote
remote: store the connection data in a private struct
|
|
1c176883
|
2018-09-07T10:36:15
|
|
remote: store the connection data in a private struct
This makes it easier to pass connection-related options around (proxy &
custom headers for now).
This fixes a bug in git_push_finish, which didn't reuse the provided
proxy if the connection closed between the call to `git_remote_push` and
the finish step.
|
|
f2694635
|
2018-09-06T14:17:54
|
|
config_file: fix quadratic behaviour when adding config multivars
In case where we add multiple configuration entries with the same key to
a diskfile backend, we always need to iterate the list of this key to
find the last entry due to the list being a singly-linked list. This
is obviously quadratic behaviour, and this has sure enough been found by
oss-fuzz by generating a configuration file with 50k lines, where most
of them have the same key. While the issue will not arise with "sane"
configuration files, an adversary may trigger it by providing a crafted
".gitmodules" file, which is delivered as part of the repo and also
parsed by the configuration parser.
The fix is trivial: store a pointer to the last entry of the list in its
head. As there are only two locations now where we append to this data
structure, mainting this pointer is trivial, too. We can also optimize
retrieval of a single value via `config_get`, where we previously had to
chase the `next` pointer to find the last entry that was added.
Using our configuration file fozzur with a corpus that has a single file
with 50000 "-=" lines previously took around 21s. With this optimization
the same file scans in about 0.053s, which is a nearly 400-fold
improvement. But in most cases with a "normal" amount of same-named keys
it's not going to matter anyway.
|
|
695067f7
|
2018-09-06T11:54:01
|
|
Merge pull request #4792 from nelhage/multiline-leak
config: Fix a leak parsing multi-line config entries
|
|
d22cd1f4
|
2018-09-05T11:49:13
|
|
Prevent heap-buffer-overflow
When running repack while doing repo writes, `packfile_load__cb()` can see some temporary files in the directory that are bigger than the usual, and makes `memcmp` overflow on the `p->pack_name` string. ASAN detected this. This just uses `strncmp`, that should not have any performance impact and is safe for comparing strings of different sizes.
```
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61200001a3f3 at pc 0x7f4a9e1976ec bp 0x7ffc1f80e100 sp 0x7ffc1f80d8b0
READ of size 89 at 0x61200001a3f3 thread T0
SCARINESS: 26 (multi-byte-read-heap-buffer-overflow)
#0 0x7f4a9e1976eb in __interceptor_memcmp.part.78 (/build/cfgr-admin#link-tree/libtools_build_sanitizers_asan-ubsan-py.so+0xcf6eb)
#1 0x7f4a518c5431 in packfile_load__cb /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb_pack.c:213
#2 0x7f4a518d9582 in git_path_direach /build/libgit2/0.27.0/src/libgit2-0.27.0/src/path.c:1134
#3 0x7f4a518c58ad in pack_backend__refresh /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb_pack.c:347
#4 0x7f4a518c1b12 in git_odb_refresh /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:1511
#5 0x7f4a518bff5f in git_odb__freshen /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:752
#6 0x7f4a518c17d4 in git_odb_stream_finalize_write /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:1415
#7 0x7f4a51b9d015 in Repository_write /build/pygit2/0.27.0/src/pygit2-0.27.0/src/repository.c:509
```
|
|
bc63e1ef
|
2018-09-03T10:49:46
|
|
config_parse: refactor error handling when parsing multiline variables
The current error handling for the multiline variable parser is a bit
fragile, as each error condition has its own code to clear memory.
Instead, unify error handling as far as possible to avoid this
repetitive code. While at it, make use of `GITERR_CHECK_ALLOC` to
correctly handle OOM situations and verify that the buffer we print into
does not run out of memory either.
|
|
38b85255
|
2018-09-01T03:50:26
|
|
config: Fix a leak parsing multi-line config entries
|
|
2054fe50
|
2018-08-30T12:41:15
|
|
Merge pull request #4781 from nelhage/multiline-loop
config: convert unbounded recursion into a loop
|
|
df2f276e
|
2018-08-26T13:22:55
|
|
Merge pull request #4765 from tiennou/fix/macos-qsort_r
util: make the qsort_r check work on macOS
|
|
85eb2cb6
|
2018-08-26T11:33:42
|
|
Merge pull request #4727 from libgit2/cmn/null-oid-existing-tree
tree: accept null ids in existing trees when updating
|
|
50186ce8
|
2018-08-26T11:26:45
|
|
Merge pull request #4374 from pks-t/pks/pack-file-verify
Pack file verification
|
|
a03113e8
|
2018-08-25T17:04:39
|
|
config: convert unbounded recursion into a loop
|
|
1a9cc182
|
2018-08-17T15:56:30
|
|
util: make the qsort_r check work on macOS
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.
|
|
9a193102
|
2018-08-24T11:01:39
|
|
Merge pull request #4774 from tiennou/fix/clang-analyzer
Coverity flavored clang analyzer fixes
|
|
503af775
|
2018-08-24T10:08:09
|
|
Merge pull request #4769 from tiennou/fix/worktree-unlock
worktree: unlock should return 1 when the worktree isn't locked
|
|
296cb5e6
|
2018-08-24T09:07:01
|
|
Merge pull request #4763 from cschlack/fix_ng_packets
Fix 'invalid packet line' for ng packets containing errors
|
|
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.
|
|
22d013b6
|
2018-08-21T01:55:56
|
|
remote: set the error before cleanup
Otherwise we'll return stack data to the caller.
|
|
ad95873b
|
2018-08-21T01:41:05
|
|
mailmap: Undefined or garbage value returned to caller
In case there was nothing to parse in the buf, we'd return uninitialized
stack data.
|
|
aa8cb586
|
2018-08-21T01:12:11
|
|
revwalk: The left operand of '<' is a garbage value
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.
|
|
50dd7fea
|
2018-08-11T13:06:14
|
|
Fix 'invalid packet line' for ng packets containing errors
|
|
59c2e70e
|
2018-08-17T00:51:51
|
|
worktree: unlock should return 1 when the worktree isn't locked
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.
|
|
581d5492
|
2018-08-16T22:45:43
|
|
Fix leak in index.c
|
|
622e12c1
|
2018-08-16T10:35:31
|
|
Merge pull request #4749 from neithernut/fix-git__linenlen-ub
parse: Do not initialize the content in context to NULL
|
|
43e7bf78
|
2018-08-16T10:27:49
|
|
Merge pull request #4750 from nelhage/nelhage-config-no-section
config_file: Don't crash on options without a section
|
|
c65568d8
|
2018-08-09T12:48:26
|
|
diff: fix OOM on AIX when finding similar deltas in empty diff
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.
|
|
b093bb56
|
2018-08-06T13:08:15
|
|
Merge pull request #4759 from pks-t/pks/ci-werror
ci: enable compilation with "-Werror"
|
|
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
|
|
0fcd0563
|
2018-08-06T12:00:21
|
|
odb: fix use of wrong printf formatters
The `git_odb_stream` members `declared_size` and `received_bytes` are
both of the type `git_off_t`, which we usually defined to be a 64 bit
signed integer. Thus, passing these members to "PRIdZ" formatters is not
correct, as they are not guaranteed to accept big enough numbers.
Instead, use the "PRId64" formatter, which is able to represent 64 bit
signed integers.
|
|
ec76a1aa
|
2018-08-05T14:37:08
|
|
Add a comment
|
|
019409be
|
2018-08-05T14:25:22
|
|
Don't error on missing section, just continue
|
|
b8a67eda
|
2018-07-22T23:47:12
|
|
Fix a double-free in config parsing
|
|
c4d7fa95
|
2018-07-22T23:31:19
|
|
config_file: Don't crash on options without a section
|
|
d1bfe614
|
2018-08-04T19:30:40
|
|
parse: Do not initialize the content in context to NULL
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.
|
|
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
|
|
a4ffbae4
|
2018-07-29T11:46:05
|
|
revwalk: remove tautologic condition for hiding a commit
The contition cannot be reached with `commit->uninteresting` being true:
either a `break` or a `continue` statement will be hit in this case.
|
|
b00a09b0
|
2018-07-27T20:14:27
|
|
Merge pull request #4731 from libgit2/ethomson/wintls_fix
winhttp: retry erroneously failing requests
|
|
f00db9ed
|
2018-07-27T12:00:37
|
|
tree: rename from_tree to validate and clarify the tree in the test
|
|
42f83840
|
2018-07-26T15:25:44
|
|
Merge pull request #4721 from nelhage/max-objects
Add a configurable limit to the max pack size that will be indexed
|
|
d4198d4d
|
2018-07-26T12:11:34
|
|
mbedtls: remove unused variable "cacert"
In commit 382ed1e87 (mbedtls: load default CA certificates, 2018-03-29),
the function `git_mbedtls_stream_global_init` was refactored to call out
to `git_mbedtls__set_cert_location` instead of setting up the
certificates itself. The conversion forgot to remove the now-unused
"cacert" variable, which is now only getting declared to be free'd at
the end of the function. Remove it.
|
|
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.
|
|
2fabb622
|
2018-07-21T01:36:46
|
|
mbedtls: free stream on shutdown
|
|
9e002cd5
|
2018-07-21T01:11:58
|
|
mbedtls: make ciphers_list a static array
Instead of allocating the ciphers_list, make it a static array. This
prevents us from leaking it or having to manage its memory.
|
|
4e62d26f
|
2018-07-21T00:45:24
|
|
mbedtls: free ciphers_list
|
|
defa9709
|
2018-07-21T00:41:38
|
|
mbedtls: check allocations
|
|
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.
|
|
32810348
|
2018-07-20T08:43:54
|
|
Use UINT32_MAX as the default object limit
This replicates the old behavior of limiting to 2³² by default.
|
|
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.
|
|
ea9e2c1a
|
2018-07-20T13:06:56
|
|
Merge pull request #4692 from tiennou/examples/checkout
Add a checkout example
|
|
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
|
|
2dff7e28
|
2018-07-18T21:04:13
|
|
tree: accept null ids in existing trees when updating
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.
|
|
b3ca817e
|
2018-07-16T03:14:33
|
|
INDEXER_MAX_OBJECTS -> PACK_MAX_OBJECTS
|
|
bfe34242
|
2018-07-16T03:12:01
|
|
See if this fixes 32-bit build
|
|
388149f5
|
2018-07-15T17:25:26
|
|
No need for this placeholder.
|
|
19007b19
|
2018-07-15T17:30:04
|
|
alloc: don't overwrite allocator during init if set
If the allocator has been set before we the library is initialised, we would
replace that setting with the standard allocator contrary to the user's wishes.
|
|
e1a4a8eb
|
2018-06-25T11:58:34
|
|
cmake: enforce C90 standard
While the aim of libgit2 was to conform to C90 code, we never instructed
the compiler to enforce C90 compliance. Thus, quite a few violations
were able to get into our code base, which have been removed with the
previous commits. As we are now able to build libgit2 with C90 enforced,
we can set the C_STANDARD property for our own build targets.
Note that we explicitly avoid setting the C standard for our third-party
dependencies. At least the zlib target does not build with C90 enforced,
and we do not want to fix them by deviating from upstream. Thus we
simply enforce no standard for them.
|
|
d19381e2
|
2018-06-25T14:57:07
|
|
mbedtls: fix `inline` being used in mbedtls headers
The mbedtls headers make direct use of the `inline` attribute to
instruct the compiler to inline functions. As this function is not C90
compliant, this can cause the compiler to error as soon as any of these
files is included and the `-std=c90` flag is being added.
The mbedtls headers declaring functions as inline always have a prelude
which define `inline` as a macro in case it is not yet defined. Thus, we
can easily replace their define with our own define, which simply copies
the logic of our own `GIT_INLINE` macro.
|
|
c13e56f9
|
2018-06-25T14:12:53
|
|
cmake: distinguish internal and system include directories
While we want to enforce strict C90 mode, this may cause issues with
system provided header files which are themselves not strictly
conforming. E.g. if a system header has C++ style comments, a compiler
in strict C90 mode would produce an error and abort the build. As the
user most likely doesn't want to change the system header, this would
completely break the build on such systems. One example of this is
mbedtls, which provides such header files.
The problem can be worked around by distinguishing between
system-provided and project-provided include directories. When adding
include directories via "-isystem" instead of "-I", the compiler will
skip certain checks and print out less warnings. To use system includes,
we can simply add the "SYSTEM" flag to CMake's `INCLUDE_DIRECTORIES` and
`TARGET_INCLUDE_DIRECTORIES` functions. Note that we have to split the
include directories into two variables because of this, as we definitely
still want to check for all warnings produced by our own header files.
|
|
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.
|
|
f347a441
|
2018-06-25T11:55:13
|
|
treewide: avoid use of `inline` attribute
ISO C90 does not specify the `inline` attribute, and as such we cannot
use it in our code. While we already use `__inline` when building in
Microsoft Visual Studio, we should also be using the `__inline__`
attribute from GCC/Clang. Otherwise, if we're using neither MSVC nor
GCC/Clang, we should simply avoid using `inline` at all and just define
functions as static.
This commit adjusts our own `GIT_INLINE` macro as well as the inline
macros specified by khash and xdiff. This allows us to enable strict C90
mode in a later commit.
|
|
efe3f37d
|
2018-07-12T04:20:15
|
|
Add a git_libgit2_opts option to set the max indexer object count
|
|
912c59c9
|
2018-06-24T06:51:08
|
|
while fuzzing, limit # objects read
|
|
6dfc8bc2
|
2018-07-09T23:10:05
|
|
Merge pull request #4719 from pks-t/pks/delta-oob
Delta OOB access
|
|
290292b4
|
2018-07-08T15:28:50
|
|
Merge pull request #4710 from pks-t/pks/ssl-init-errors
streams: report OpenSSL errors if global init fails
|
|
698b4463
|
2018-06-23T13:06:10
|
|
annotated_commit: make the refname accessible
As git_annotated_commit seems to behave like cgit's refish, it's quite
helpful to abstract away "targets" via git_annotated_commit_from_id/from_ref.
As the former is accessible via git_annotated_commit_id, make the latter
also available to users.
|
|
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
|
|
36a5b557
|
2018-06-19T20:18:26
|
|
submodule: don't leak memory when failing to insert the names
Reported by Coverity, CID 1393237
|
|
ca9bbcb5
|
2018-06-19T20:15:02
|
|
blame: check error code when loading the mailmap
Reported by Coverity, CID 1393484
|
|
f4633791
|
2018-07-06T12:36:05
|
|
Merge pull request #4687 from tiennou/fix/4672
patch_parse: populate line numbers while parsing diffs
|
|
f2a1cece
|
2018-07-06T11:25:47
|
|
Merge pull request #4686 from tiennou/fix/more-worktree-from-bare
Fix git_worktree_validate failing on bare repositories
|
|
8a00de08
|
2018-07-06T10:47:06
|
|
Merge pull request #4699 from nelhage/fetch-null-dst
git_refspec_transform: Handle NULL dst
|
|
75395c87
|
2018-06-29T13:35:14
|
|
streams: report OpenSSL errors if global init fails
In case when the global initialization of the OpenSSL stream fails, the
user is left without any hint as to what went wrong as we do not provide
any error message at all. This commit refactors the init function to
have a common error path, which now also sets an error message including
the error string provided by OpenSSL.
|
|
e087c0de
|
2018-07-05T13:30:46
|
|
delta: fix overflow when computing limit
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>
|
|
c43658f6
|
2018-06-30T13:24:23
|
|
Merge pull request #4536 from libgit2/ethomson/index_dirty
Add a "dirty" state to the index when it has unsaved changes
|
|
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
|
|
bfa1f022
|
2018-06-22T19:17:08
|
|
settings: optional unsaved index safety
Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause
commands that reload the on-disk index to fail if the current
`git_index` has changed that have not been saved. This will prevent
users from - for example - adding a file to the index then calling a
function like `git_checkout` and having that file be silently removed
from the index since it was re-read from disk.
Now calls that would re-read the index will fail if the index is
"dirty", meaning changes have been made to it but have not been written.
Users can either `git_index_read` to discard those changes explicitly,
or `git_index_write` to write them.
|
|
787768c2
|
2018-06-22T19:07:54
|
|
index: return a unique error code on dirty index
When the index is dirty, return GIT_EINDEXDIRTY so that consumers can
identify the exact problem programatically.
|
|
5e26391a
|
2018-06-18T18:28:08
|
|
checkout: FORCE doesn't halt on dirty index
If the index is dirty, allow `GIT_CHECKOUT_FORCE` to obliterate unsaved
changes. This is in keeping with its name and description.
|
|
b242cdbf
|
2017-11-17T00:19:07
|
|
index: commit the changes to the index properly
Now that the index has a "dirty" state, where it has changes that have
not yet been committed or rolled back, our tests need to be adapted to
actually commit or rollback the changes instead of assuming that the
index can be operated on in its indeterminate state.
|
|
7c56c49b
|
2017-11-12T08:09:35
|
|
index: add a dirty bit reflecting unsaved changes
Teach the index when it is "dirty", and has unsaved changes. Consider
the index dirty whenever a caller has added or removed an entry from the
main index, REUC or NAME section, including when the index is completely
cleared. Similarly, consider the index _not_ dirty immediately after it
is written, or when it is read from the on-disk index.
This allows us to ensure that unsaved changes are not lost when we
automatically refresh the index.
|
|
4919e495
|
2018-02-18T23:55:56
|
|
stash: use _an_ index not _the_ index
Don't manipulate the repository's index during stash; instead,
manipulate a temporary index and check it out.
This allows us to use the checkout mechanism to update the workdir and
the repository's index, and allows checkout to use its common mechanisms
to write data and handle errors.
|
|
1da6329f
|
2018-06-29T14:39:17
|
|
worktree: don't return "untyped" negative numbers as error codes
|
|
292a6eca
|
2018-06-29T14:39:16
|
|
worktree: skip building a buffer when validating
|
|
83c35f7e
|
2018-06-29T14:39:11
|
|
tests: worktree/bare: fix git_worktree_validate
|
|
68e73791
|
2018-06-29T12:52:35
|
|
Merge pull request #4709 from pks-t/pks/refspec-dispose
refspec: rename `git_refspec__free` to `git_refspec__dispose`
|
|
01574d40
|
2018-06-29T11:28:17
|
|
Merge pull request #4701 from nikital/master
streams: openssl: Handle error in SSL_CTX_new
|
|
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.
|
|
7192e26f
|
2018-06-29T09:43:33
|
|
Merge pull request #4519 from cynecx/refspec-parsing
refspec: add public parsing api
|
|
24597812
|
2018-06-29T09:11:02
|
|
delta: fix out-of-bounds read of delta
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>
|
|
7db25870
|
2018-06-29T07:45:18
|
|
delta: fix sign-extension of big left-shift
Our delta code was originally adapted from JGit, which itself adapted it
from git itself. Due to this heritage, we inherited a bug from git.git
in how we compute the delta offset, which was fixed upstream in
48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As
explained by Linus:
Shifting 'unsigned char' or 'unsigned short' left can result in sign
extension errors, since the C integer promotion rules means that the
unsigned char/short will get implicitly promoted to a signed 'int' due to
the shift (or due to other operations).
This normally doesn't matter, but if you shift things up sufficiently, it
will now set the sign bit in 'int', and a subsequent cast to a bigger type
(eg 'long' or 'unsigned long') will now sign-extend the value despite the
original expression being unsigned.
One example of this would be something like
unsigned long size;
unsigned char c;
size += c << 24;
where despite all the variables being unsigned, 'c << 24' ends up being a
signed entity, and will get sign-extended when then doing the addition in
an 'unsigned long' type.
Since git uses 'unsigned char' pointers extensively, we actually have this
bug in a couple of places.
In our delta code, we inherited such a bogus shift when computing the
offset at which the delta base is to be found. Due to the sign extension
we can end up with an offset where all the bits are set. This can allow
an arbitrary memory read, as the addition in `base_len < off + len` can
now overflow if `off` has all its bits set.
Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned
integer again. Add a test with a crafted delta that would actually
succeed with an out-of-bounds read in case where the cast wouldn't
exist.
Reported-by: Riccardo Schirone <rschiron@redhat.com>
Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
|