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.
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.
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
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
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.
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
Remove deprecated OpenSSH configuration options from ci/test.sh:
- Protocol 2 (deprecated since OpenSSH 7.4)
- RSAAuthentication (deprecated since OpenSSH 7.4)
- ChallengeResponseAuthentication (deprecated since OpenSSH 9.6)
- HostCertificate pointing to .pub file (invalid configuration)
- Duplicate HostKey directive
These options were causing warnings with OpenSSH 10.0 in Fedora Rawhide
and preventing SSH tests from functioning properly.
Tested with OpenSSH 10.0p2 on Fedora Rawhide.
This patch makes two improvements:
1. In case of LIBSSH2_ERROR_TIMEOUT, don't loop forever
2. Enable TCP keepalive on all sockets to detect dead connections
The added test demonstrates the hang without the patch.
Regardless of which reference storage format is used, pseudorefs will
always be looked up via the filesystem as loose refs. This is because
pseudorefs do not strictly follow the reference format and may contain
additional metadata that is not present in a normal reference.
We don't honor this in `git_reference_lookup()` though but instead defer
to the refdb to read such references. This obviously works just fine
with the "files" backend, but any other backend would have to grow
custom logic to handle reading pseudorefs.
Refactor `git_reference_lookup_resolved()` so that it knows to always
read pseudorefs as loose references. This allows refdb implementations
to not care about pseudoref handling at all.
With the preceding commit we have refactored the "files" backend so that
it can be both instantiated and used to look up a reference without
reading any configuration. With this change in place we don't cause
infinite recursion anymore when using the refdb to evaluate "onbranch"
conditions.
Refactor the code to use the refdb to look up "HEAD". Note that we
cannot use `git_reference_lookup()` here, as that function itself tries
to normalize reference names, which in turn involves reading the Git
configuration. So instead, we use the lower-level `git_refdb_lookup()`
function, as we don't need the normalization anyway.
When initializing the "files" refdb we read a couple of values from the
Git configuration. Unfortunately, this causes a chicken-and-egg problem
when reading configuration with "includeIf.onbranch" conditionals: we
need to instantiate the refdb to evaluate the condition, but we need to
read the configuration to initialize the refdb.
We currently work around the issue by reading the "HEAD" file directly
when evaluating the conditional include. But while that works with the
"files" backend, any other backends that store "HEAD" anywhere else will
break.
Prepare for a fix by deferring reading the configuration. We really only
need to be able to execute `git_refdb_lookup()`, so all we need to
ensure is that we can look up a branch without triggering any config
reads.
Introduce the GIT_HEAD_REF define so that we can clearly indicate that
we're talking about the "HEAD" reference and not necessarily a file.
Note that there still are a couple of places where GIT_HEAD_FILE is
being used:
- `git_repository_create_head()`: This function is used to create HEAD
when initializing a new repository. This should get fixed eventually
so that we create HEAD via the refdb, but this is a more involved
refactoring that will be handled in a separate patch series.
- `repo_init_head()`: Likewise.
- `conditional_match_onbranch()`: This function is used to decide
whether or not an `includeIf.onbranch` condition matches. This will
be fixed in subsequent commits.
Other than that there shouldn't be any more references to GIT_HEAD_FILE.
The GIT_STASH_FILE define contains the path to the stash reference.
While we know that this used to be a file with the "files" backend, it's
not a standalone file with the "reftable" backend anymore.
Rename the macro to GIT_STASH_REF to indicate that this is a proper ref.
We have a bunch of references that we treat like pseudo-refs. Those
references are (sometimes) read and written by going to the filesystem
directly, at other times they are read and written via the refdb. This
works alright with the "files" ref storage format given that any root
reference never gets packed into the "packed-refs" file, and thus they
would always be accessible a loose ref if present.
The behaviour is wrong though when considering alternate backends like
the "reftable" backend. All references except for pseudo-refs must be
read via the backend, and that includes root refs.
Historically this part of Git has been ill-defined, and it wasn't quite
clear which refs are considered pseudo-refs in the first place. This was
clarified in 6fd80375640 (Documentation/glossary: redefine pseudorefs as
special refs, 2024-05-15): there only are two pseudorefs, "FETCH_HEAD"
and "MERGE_HEAD". The reason why those two references are considered
special is that they may contain additional data that doesn't fit into
the normal reference format.
In any case, our current handling of a couple of root references is
broken in this new world.
Fix this for "ORIG_HEAD" by exclusively going through the refdb to read
and write that reference. Rename the define accordingly to clarify that
it is a reference and not a file.
