The `USE_` prefix for inputs denotes a backend; the `DEBUG_` prefix
denotes a debugging option. Make `DEBUG_LEAK_CHECKER` the name of the
leak checking option.
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.
Ensure that workflows where the main branch exists (eg, anything except
PR workflows) don't try to recreate the main branch. Add a concurrency
token so that we don't have conflicts generating documentation.
libgit2 has a new documentation generator that generates API schema from
our headers, then produces reference documentation that is included into
the website directly.
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
Update the nightly and benchmark workflows to only run steps in
libgit2/libgit2 by default. Also update the benchmark workflow to use
the latest download-artifact version.
Split the SHA256 builds into their own workflow; since they're
experimental (and have proven to be flaky) they shouldn't be used as
signal that there's a problem with a PR.
