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.
