By placing the X509 cert constant option in the middle of the existing
options, it renumbers everything unnecessarily. Move it to the end in
to avoid breaking changes.
In RPC mode (https), the client sends its list of shallow commits at the
beginning of each request during packfile negotiation, so that the
remote endpoint keeps context. This causes the remote to prepend
appropriate shallow/unshallow packets to each response sent back to the
client.
However, the store_common() helper function (used in multi_ack mode)
does not cater for this, returning as soon as it encounters any packet
different than an ACK packet and therefore leaving the rest of the HTTP
buffer unprocessed. This in turn causes subsequent iterations of the
while loop processing ACK packets to process data returned by older HTTP
requests instead of the current one, messing up the packfile negotiation
process. Given that the wait_while_ack() helper function (called after
the client signals to the remote that it is ready to receive packfile
data) correctly skips over shallow/unshallow packets, packfile contents
can still be received successfully in some cases (depending on message
framing); in some other ones, though (particularly when
git_smart__download_pack() processes an HTTP buffer starting with
shallow/unshallow packets), the fetching process fails with an
"incomplete pack header" error due to the flush packet terminating a set
of shallow/unshallow packets being incorrectly interpreted as the flush
packet indicating the end of the packfile (making the code behave as if
no packfile data was sent by the remote).
Fix by ignoring shallow/unshallow packets in the store_common() helper
function, therefore making the ACK processing logic work on the correct
HTTP buffers and ensuring that git_smart__download_pack() is not called
until packfile negotiation is actually finished.
Provide a mechanism to understand the backend provider for feature
within libgit2. For example, one can query the mechanism that provides
HTTPS by asking for the backend for the `GIT_FEATURE_HTTPS`.
This is particularly useful for features that are not completely
isomorphic; the HTTPS providers may have slightly different
functionality that can be controlled (eg, certificates or cipher
support). And the SSH feature is _very_ different between libssh2 and
OpenSSH.
It may also be useful to understand the support for things like the SHA1
or SHA256 backends to ensure that sha1dc is used, or that FIPS mode is
enabled.
Removing TLS v1.0 and v1.1 support is a bit of a breaking change; making
that change without any announcement or preparation is rather unkind.
Defer the TLS v1.2 requirement to the next version, but update the
cipher selection to the Mozilla backward compatibility list.
Instead of making the commit and dump functions take individual options
structures; provide the options structure to the writer creator. This
allows us to add additional information (like OID type) during
generation.
Add support for fetching with negative refspecs. Fetching from the
remote with a negative refspec will now validate any references fetched
do not match _any_ negative refspecs and at least one non-negative
refspec. As we must ensure that fetched references do not match any of
the negative refspecs provided, we cannot short-circuit when checking
for matching refspecs.
Negative refspecs were added in Git v2.29.0 and are denoted by prefixing
a refspec with a caret. This adds a way to distinguish if a refspec is
negative and match negative refspecs.
Update our default cipher list to the most recent "intermediate"
configuration from Mozilla's SSL cipher list, which is "recommended
cnofiguration for a general-purpose server".
https://wiki.mozilla.org/Security/Server_Side_TLS
This removes many outdated ciphers that are no longer practically
supported by servers, including GitHub, GitLab, and Bitbucket.
In RPC mode (https), we need to resend the data so that the remote
endpoint keeps context. In non-RPC mode, we need not (and should not)
resend it. Clear that buffer data in non-RPC mode to prevent this.
