Now that we have two types of object IDs, with different sizes, we
expect shorter object ID types (in other words, SHA1 object ids) to be
zero-padded at their suffix. This allows us to use faster comparison and
copy routines over the entirety of the structure, instead of trying to
examine the type and then do a comparison of the appropriately sized
structure.
For pure manipulation of object IDs, this produces parity with the
SHA1-only object ID code.
SHA1:
oid::cmp_sha1: 8.065 ms ± 703.9 μs / range: 7.875 ms … 14.88 ms (201 runs)
oid::cmp_sha256: skipped
oid::cpy_sha1: 5.340 ms ± 47.26 μs / range: 5.272 ms … 5.617 ms (548 runs)
oid::cpy_sha256: skipped
oid::zero_sha1: 5.327 ms ± 49.27 μs / range: 5.271 ms … 5.612 ms (553 runs)
oid::zero_sha256: skipped
SHA256 (before this change; testing the `type`):
oid::cmp_sha1: 10.82 ms ± 1.029 ms / range: 10.57 ms … 20.63 ms (145 runs)
oid::cmp_sha256: 10.63 ms ± 103.9 μs / range: 10.50 ms … 11.48 ms (279 runs)
oid::cpy_sha1: 26.13 ms ± 63.91 μs / range: 26.07 ms … 26.45 ms (113 runs)
oid::cpy_sha256: 20.92 ms ± 58.32 μs / range: 20.86 ms … 21.25 ms (141 runs)
oid::zero_sha1: 13.19 ms ± 129.1 μs / range: 13.11 ms … 13.72 ms (224 runs)
oid::zero_sha256: 13.12 ms ± 30.06 μs / range: 13.10 ms … 13.30 ms (225 runs)
SHA256 (with this change):
oid::cmp_sha1: 7.985 ms ± 562.3 μs / range: 7.874 ms … 14.32 ms (209 runs)
oid::cmp_sha256: 6.609 ms ± 30.77 μs / range: 6.584 ms … 6.870 ms (443 runs)
oid::cpy_sha1: 5.282 ms ± 21.90 μs / range: 5.266 ms … 5.524 ms (543 runs)
oid::cpy_sha256: 5.279 ms ± 17.57 μs / range: 5.263 ms … 5.415 ms (554 runs)
oid::zero_sha1: 5.288 ms ± 22.92 μs / range: 5.268 ms … 5.508 ms (544 runs)
oid::zero_sha256: 5.286 ms ± 21.29 μs / range: 5.271 ms … 5.527 ms (542 runs)
When we were done reading headers, we checked if we needed to read a
body, or if we were done. The body check was done by looking at the
transfer encoding type and the content type. If we were chunked, then we
know we have a body (it may be a zero byte body, but we would need to
read the chunk length to know this). But looking at the content _type_
was erroneous; we should have been looking at the content _length_.
The effect of this is that when a server sends a zero byte response
with a content _type_, we try to go read the body, which does not exist.
We will hang waiting for the body that the server will never send.
Correct this typo. Now we will try to read the body if there was a
content _length_ specified, or if the transfer encoding is chunked.
poxygit now supports a "specification" within the URI that can provide
additional details about the mock/debugging connection. The `:none`
suffix on the redirect request indicates that the proxy should send a 0
byte response body.
Update our CI to use poxygit v0.8.1, which has additional mocking and
debugging capabilities.
As part of this, the paths to the `speed` test routes changed - now they
are `speed:<n>` where `<n>` is the speed to emulate in bps.
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.
