In cases when a path is missing from the ancestor and only of the two
children is defined (IOW, the object is added), then the path in the child
that is defined should be returned.
However, merge_file__best_path is only returning a path in cases when there
is no ancestor path only if both children are defined and they match each
other.
Improve merge_file__best_path by handling the case when it is present in
only one of the children paths returning this value.
Depending on the zlib library used, the inflate() function may write
beyond the object size into the additional trailing buffer for aligned
memory copies. This may cause out-of-bounds memory read if the object
buffer is later used without checking the object size, as in
git_commit__extract_signature.
Link: https://github.com/zlib-ng/zlib-ng/issues/1767
Signed-off-by: Kan-Ru Chen <kanru@kanru.info>
Avoid a buffer overrun when an object's header specifies a short length
but the body is longer (fix#7177). Take care to preserve the behavior
that too-short object bodies are not an error but get zero-padded.
Instead of regenerating `git2.h` on every cmake invocation, use
`configure_file` to avoid rewriting it. This keeps timestamps inline and
avoids unnecessarily rebuilding the library.
The strstr call used to find the " object-format=" capability string did
not have a length limit, potentially reading past the end of the
allocated buffer if the capabilities string was not null-terminated
within the buffer bounds. Replaced strstr with git__memmem and
subsequent strchr calls with memchr, providing the remaining buffer
length as a limit to prevent out-of-bounds reads.
https: //oss-fuzz.com/testcase-detail/4895812384325632
https: //issues.oss-fuzz.com/issues/42524461
Change-Id: Id313af1bce48ea8763fa2dfd7eb9ee8934fa541f
Cache `oid_type` in `transport_local` struct during `connect()`
so `git_remote_oid_type()` keeps working after disconnect.
This matches the smart transport behavior.
Exercise git_remote_oid_type on a SHA256 local transport.
The after-disconnect assertion is commented out because
local_oid_type dereferences `t->repo`, which local_close
has already freed (SIGSEGV).
I ran these commands to test btw:
```
cmake .. -DGIT_EXPERIMENTAL_SHA256=ON -DBUILD_TESTS=ON
cmake --build .
./libgit2_tests -snetwork::remote::local::sha256_oid_type
```
Detached remotes already read global/system config for http proxy
settings, but did not apply url.*.insteadOf or url.*.pushInsteadOf
rules. This inconsistency meant that `git_remote_create_detached`
behaved differently from git's `ls-remote`, which was the primary
use case for detached remotes.
This fixes it by loading the default config when no repository is
provided and apply insteadOf rules consistently.
While this is a behavior change, it still respects
`GIT_REMOTE_CREATE_SKIP_INSTEADOF`, meaning that user can restore
the previous behavior with minimal effort
Fixes https://github.com/libgit2/libgit2/issues/5469
`git_remote_create_detached` does not apply
`url.*.insteadOf` or url.*.pushInsteadOf from global config.
These tests currently pass, asserting the buggy behavior
and serving as a minimal reproduction.
The assertions will be updated when the fix is applied.
See <https://github.com/libgit2/libgit2/issues/5469>
`clone_local_into()` copies objects from the source repository
but does not set the destination's object format.
This cause SHA256 repositories to be unreadable after a local clone
because the destination defaults to SHA1.
The remote clone path already handles this correctly
so local clone path follows suite.
See: <https://github.com/libgit2/libgit2/blob/1f34e2a57/src/libgit2/clone.c#L448-L450>
Local clone, both hardlink and copy paths, does not propagate
the source repository's object format to the destination.
A SHA256 repository cloned locally is initialized as SHA1
and caused object lookup failures.
These tests are added as reproducible examples,
and will be fixed in the next commit
* `sha256_via_no_local`
* `file://` URL + `GIT_CLONE_NO_LOCAL` -> remote code path
* `sha256_object_format_is_propagated`
* `file://` URL + `GIT_CLONE_LOCAL` -> local code path with hardlinks
* `sha256_no_links_object_format_is_propagated`
* `file://` URL + `GIT_CLONE_LOCAL_NO_LINKS` -> local code path with copy
The fallback definition of O_FSYNC uses `(1 << 31)`, which is undefined
behavior in C. The literal `1` is a signed int, and left-shifting into
the sign bit of a signed integer is undefined per the C standard.
This causes crashes on arm64 Linux with musl libc (which doesn't define
O_FSYNC), manifesting as:
thread panic: left shift of 1 by 31 places cannot be represented
in type 'int'
Fall back to O_SYNC when available, since it is the POSIX standard name
for the same flag. On platforms where neither is defined (e.g. Windows),
use (1 << 30) as a sentinel value that avoids the sign bit.
We need this in order for `pkg-config` to be able to tell what you should link
against when building libgit2 statically. We do include libssh2 in
`Libs.private` but not in `Requires.private`. The difference is a bit subtle but
has become important.
You can call `pkg-config --libs --static ${build}/libgit2.pc` and it will give
you what is in the Libs line, and also what the packages from the Requires field
have in theirs. This is what e.g. `rugged` does and it has been working until
recently. An update to openssl to require zstd now means that using `--libs
--static` returns `-lzstd` as well as many others. This means that those who
want to link using that command now need to have the development packages for
zstd installed, which should not be necessary as libgit2 itself doesn't want to
use anything from it.
A better command to use here seems to be `pkg-config --libs --static --pure
${build}/libgit2.pc`. The manpage and help output are not very precise but what
this does is limit the list of dependencies to a single layer, which is what we
want as we would only want to link statically against libgit2 and not the rest
of the libraries.
But trying to do so breaks building with libssh2 as it's included in the Libs
field rather than the Requires, so that command excludes any linking to libssh2.
Put libssh2 in the `Requires.private` field so we correctly express we need to
link to it when linking statically.
This is unfortunately an imperfect fix as now, if we did not find libssh2 via
pkg-config but rather via CMake's `find_package`, the combination of `--static
--pure` does not take `Libs.private` into account. However we only support this
as an edge case and we expect `pkg-config` to be available for the rest of our
dependencies.
Preserve ref-advertised capabilities when only the stream is reset.
This prevents losing `object-format` before `git_remote_oid_type()`
and fixes SHA256 clone pack trailer mismatch.
Fixeslibgit2/libgit2#7182
This would be useful for user to determine whether they want to proceed
or bail further remote operations. Particularily useful for downstream
libgit2 bindings and applications to experiment SHA256 support behind a
runtime feature flag.
For example, `cargo` could compile with sha256 support unconditionally,
but reject SHA256 usage at runtime if the `-Zgit=sha256` nightly flag
was not on. Cargo would leverage this new API to determine if users are
trying to fetch a SHA256 remote repository and bail when needed before
any fetches happen.
Note that this is not gated behind `GIT_EXPERIMENTAL_SHA256` as the
oid_type is sha1 and available always.
src\libgit2\transports\auth_negotiate.h redefines git_http_auth_negotiate as git_http_auth_dummy if GIT_AUTH_NEGOTIATE is not defined, which thus leads to the uncommented code actually being a redifintion of git_http_auth_dummy. The linker complained [Windows 11, MSVC 2022 64bit].
Since git_oid_raw_cmp uses memcmp, it's far easier to optimise more aggressively.
Given that it's static const and used inlined, it seems reasonable to assume that git_oid_zero will be optimised away in release.
This is at least the case with x86-64 and GCC 15.2.1.
These are SHA256 TODO leftover.
In the surrounding context they all have the required oid type around,
so I just picked up them and pass in.
Found during SHA256 support integration with Rust git-rs binding
The expression (c & 0x7f) << shift in hdr_sz() causes undefined
behavior when shift >= 32, because (c & 0x7f) is an unsigned int
(32-bit type). A malicious delta with a long varint can trigger this.
Fix by:
1. Casting to size_t before shifting to support 64-bit shifts
2. Adding a shift limit check to reject overlong varints
