When `-DUSE_HTTP_PARSER=...` is specified, ensure that the specified
HTTP Parser is valid, do not fallback to builtin.
Restore `-DUSE_HTTP_PARSER=system` for backcompatibility.
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.
Some minor refactoring for iOS:
- Roll back clar changes; these should be a bit more measured, and occur
in clar upstream.
- Move iOS to nightly builds
We may want to support SSH but with a different provider that is not
libssh2. Add GIT_SSH to indicate that we have some inbuilt SSH support
and GIT_SSH_LIBSSH2 to indicate that support is via libssh2. This is
similar to how we support GIT_HTTPS and GIT_OPENSSL, for example.
since f15c8ac71a libgit unconditionally depends on secur32 on Windows
but only added it in cmake for the winhttp and schannel variants.
In case libgit is built against openssl it would fail to link.
This moves secur32 out of the https backend selection code into
the global win32 condition (and while at it also adds ws2_32 to the .pc file)
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).
xdiff is a dependency (from git core) and more properly belongs in the
'deps' directory. Move it there, and add a stub for cmake to resolve
xdiff from the system location in the future. (At present, bundled xdiff
remains hardcoded.)
Not everybody builds libgit2 using cmake; provide an `experimental.h`
with no experiments configured for those that do not. To support this,
we also now create compile definitions for experimental functionality,
to supplant that empty `experimental.h`. cmake will continue to generate
the proper `experimental.h` file for use with `make install`.
libgit2 can be built with optional, experimental sha256 support. This
allows consumers to begin testing and providing feedback for our sha256
support while we continue to develop it, and allows us to make API
breaking changes while we iterate on a final sha256 implementation.
The results will be `git2-experimental.dll` and installed as
`git2-experimental.h` to avoid confusion with a production libgit2.
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.
Fix building against system http-parser library by fixing
the find_package() argument. It seems to have been accidentally changed
from HTTPParser to HTTP_Parser in de178d36f, effectively making
the build against system library fail to find it:
```
CMake Warning at cmake/SelectHTTPParser.cmake:3 (find_package):
By not providing "FindHTTP_Parser.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"HTTP_Parser", but CMake did not find one.
Could not find a package configuration file provided by "HTTP_Parser" with
any of the following names:
HTTP_ParserConfig.cmake
http_parser-config.cmake
Add the installation prefix of "HTTP_Parser" to CMAKE_PREFIX_PATH or set
"HTTP_Parser_DIR" to a directory containing one of the above files. If
"HTTP_Parser" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
src/CMakeLists.txt:97 (include)
CMake Error at cmake/SelectHTTPParser.cmake:11 (message):
http-parser support was requested but not found
Call Stack (most recent call first):
src/CMakeLists.txt:97 (include)
```
On macOS, since Big Sur, the libraries were moved to a cache. The SDK comes
with stubs in the SDK (`/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib/`
or whatever SDK version one has installed) where most have the `.tbd` suffix
(although some still are `.a`). Forcing `CMAKE_FIND_LIBRARY_SUFFIXES` on Apple
platforms broke building, unless one has copies of the libraries installed
elsewhere (like Brew), as many libraries (like `iconv` or `pcre`) are not
found.
This fix disables setting the `CMAKE_FIND_LIBRARY_SUFFIXES` to `.a` if
the platform is `APPLE` when building static libs.
Also applies to *_BINARY_DIR.
This effectively reverts 84083dcc8b,
which broke all users of libgit2 that use it as a CMake subdirectory
(via `add_subdirectory()`). This is because CMAKE_SOURCE_DIR refers
to the root-most CMake directory, which in the case of
`add_subdirectory()` is a parent project to libgit2 and thus the paths
don't make any sense to the configuration files. Corollary,
CMAKE_SOURCE_DIR only makes sense if the CMake project is always the
root project - which can rarely be guaranteed.
In all honesty, CMake should deprecate and eventually remove
CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. It's been the source of headaches
and confusion for years, they're rarely useful over
CMAKE_CURRENT_(SOURCE|BINARY)_DIR or PROJECT_(SOURCE|BINARY)_DIR,
and they cause a lot of confusing configuration and source
code layouts to boot.
Any time they are used, they break `add_subdirectory()` almost 100% of
the time, cause confusing error messages, and hide subtle bugs.
