It's hard to remember whether it's `-DUSE_HTTPS=mbedTLS` or
`-DUSE_HTTPS=mbedtls`. Even worse for things like `builtin` which we may
have been inconsistent about. Allow for case insensitive options.
There were a few oddities around HTTPS provider selection: namely,
`GIT_OPENSSL_DYNAMIC` implied `GIT_OPENSSL`, which made a bit of sense,
until we added FIPS support. In addition, dynamic OpenSSL for _hashes_
and dynamic OpenSSL for HTTPS was conflated in a few places.
Untangle these, and make `GIT_HTTPS_*` the define, for consistency with
other feature provider selection.
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.
Usage of the deprecated 'SHA256_*' OpenSSL API in a FIPS compliant
environment results in OpenSSL's assertion failure with the following
description:
"OpenSSL internal error, assertion failed: Low level API call to
digest SHA256 forbidden in FIPS mode!"
This commit adds a possibility to use the OpenSSL's 'EVP_MD*' API instead
of the deprecated 'SHA256_*' API, by extending the optional CMake flag
'USE_SHA256' with the new option called 'OpenSSL-FIPS'.
The new option is used to choose a hashing backend used by libgit2 to
calculate SHA256 hashes, in a similar way that currently existing
options like 'OpenSSL', 'OpenSSL-Dynamic', 'mbedTLS' etc do.
'OpenSSL-FIPS' is a fully opt-in option which is purposely not
interfering with the existing options, because, after running some
benchmarks, it's been discovered that using the 'EVP_MD*' API causes
hashing to be a bit slower in comparison to using the deprecated
'SHA256_*' API.
Another change introduced in this commit is the enhancement of the
Nightly workflow (nightly.yml) which will cause libgit2 to be
automatically built with '-DUSE_SHA256="OpenSSL-FIPS"' CMake flag,
on Linux, macOS and Windows.
Provide a stream interface for Schannel - the native crypto APIs - on
Windows. This allows Windows to use the same HTTP transport that all the
other platforms use, with its own native crypto.
Ultimately this allows us to deprecate WinHTTP and we need not add
support for our socket changes in two places (our HTTP stack and the
WinHTTP stack).
Remove the "generic" implementation; it should never be used; it only
existed for a no-dependencies configuration, and our bundled sha1dc
satisfies that requirement _and_ is correct.
Instead of simply including the utility files directly, make them a
cmake object library for easy reusability between other projects within
libgit2.
Now the top-level `src` is responsible for platform selection, while the
next-level `libgit2` and `util` configurations are responsible for
identifying what objects they include.
Our custom CMake module currently live in "cmake/Modules". As the
"cmake/" directory doesn't contain anything except the "Modules"
directory, it doesn't really make sense to have the additional
intermediate directory. So let's instead move the modules one level up
into the "cmake/" top level directory.
