Don't build docs on pushes to maint branches; those docs should only be
built _on release_. In addition, be safer about not creating an existing
branch from a tracking branch.
git's hash algorithm is sha1dc, it is not sha1. Per Linus:
> Honestly, git has effectively already moved from SHA1 to SHA1DC.
>
> So the actual known attack and weakness of SHA1 should simply not be
> part of the discussion for the next hash. You can basically say "we're
> _already_ on the second hash, we just picked one that was so
> compatible with SHA1 that nobody even really noticed.
Warn users who try to compile with SHA1 instead of SHA1DC.
Update the library's (API) version number to v1.9.0. Also update the
soname version number to 2.0, since we've had breaking ABI changes
to the library.
For enum values that are constructed, not literal integers, we need to
parse the inner / implicit expression. For example:
```
GIT_DIFF_REVERSE = (1u << 0)
```
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.
