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>
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.
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>
The loose ref lookup helper was exposed by 7f35dc581
and then used by b17ecb23e directly for pseudoref lookup.
While investigating the pseudoref owner regression,
I found that the helper also returns success
with a NULL output reference when `git_reference__alloc()`
or `git_reference__alloc_symbolic()` failed.
This fixes it by reporting allocation failures inside
`git_reference__lookup_loose`.
Pseudoref lookup now reads `FETCH_HEAD` directly as a loose ref,
but callers still expect looked-up references to know their owning
repository.
Attach the repo's refdb after the loose pseudoref is read so
owner-dependent ops such as peeling can safely resolve objects.
b17ecb23e changed pseudoref lookup to read loose refs directly,
bypassing refdb lookup.
This documents the resulting buggy behavior:
a looked-up `FETCH_HEAD` pseudoref has no owning refdb attached.
`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
Wire up reftable tests so that they can be executed by setting the
`CLAR_REF_FORMAT` environment variable. This only catches tests that use
`cl_git_sandbox_init()`, but that should cover most of our tests. So
this infrastructure isn't perfect, but for now it's good enough. We may
want to iterate on it in the future.
Generate test resources for reftables. These resources are basically the
Git repositories we already have, but converted to use the "reftable"
format. For most of the part, this conversion is done by executing `git
refs migrate`.
A couple notes:
- This require a recent Git upstream version with not-yet-upstreamed
patches due to a bug in `git refs migrate` with reflogs.
- The migration command does not yet support repositories with
worktrees. Those were converted by first removing the worktrees,
migrating the refs and then recreating them.
- The HEAD_TRACKER reference in testrepo.git is not recognized as a
root ref and is thus not automatically migrated.
- testrepo.git has an empty reflog for refs/heads/with-empty-log that
does not get migrated.
Extract the function `is_per_worktree_ref()` from the "files" backend
and expose it via "refs.h". This function will be reused by the
"reftable" backend.
While the reftable library is mostly decoupled from the Git codebase,
some specific functionality intentionally taps into Git subsystems. To
make porting of the reftable library easier all of these are contained
in "system.h" and "system.c".
Reimplement those compatibility shims so that they work for libgit2.
Import the reftable library from commit 4fee6ff3b2 (Merge branch
'ps/reftable-portability', 2026-04-08). This is an exact copy of the
reftable library.
The library will be wired into libgit2 over the next couple of commits.
In our util headers we expose the `GIT_INLINE()` macro to declare a
function as inline, but we don't provide a way to access the keyword
directly.
Expose a new `GIT_INLINE_KEYWORD` to fill this gap. This define will be
used in a subsequent commit.
