2017-08-15 20:04:16 +08:00
|
|
|
/* Plumbing with collition-detecting SHA1 code */
|
2017-05-20 19:54:28 +08:00
|
|
|
|
2017-12-09 06:29:59 +08:00
|
|
|
#ifdef DC_SHA1_EXTERNAL
|
2017-08-15 20:04:17 +08:00
|
|
|
#include <sha1dc/sha1.h>
|
2017-12-09 06:29:59 +08:00
|
|
|
#elif defined(DC_SHA1_SUBMODULE)
|
|
|
|
#include "sha1collisiondetection/lib/sha1.h"
|
2017-08-15 20:04:16 +08:00
|
|
|
#else
|
|
|
|
#include "sha1dc/sha1.h"
|
|
|
|
#endif
|
2017-05-20 19:54:28 +08:00
|
|
|
|
2017-08-15 20:04:17 +08:00
|
|
|
#ifdef DC_SHA1_EXTERNAL
|
|
|
|
void git_SHA1DCInit(SHA1_CTX *);
|
|
|
|
#else
|
|
|
|
#define git_SHA1DCInit SHA1DCInit
|
|
|
|
#endif
|
|
|
|
|
2017-08-15 20:04:16 +08:00
|
|
|
void git_SHA1DCFinal(unsigned char [20], SHA1_CTX *);
|
2017-05-20 19:54:28 +08:00
|
|
|
void git_SHA1DCUpdate(SHA1_CTX *ctx, const void *data, unsigned long len);
|
|
|
|
|
Makefile & test-tool: replace "DC_SHA1" variable with a "define"
Address the root cause of technical debt we've been carrying since
sha1collisiondetection was made the default in [1]. In a preceding
commit we narrowly fixed a bug where the "DC_SHA1" variable would be
unset (in combination with "NO_APPLE_COMMON_CRYPTO=" on OSX), even
though we had the sha1collisiondetection library enabled.
But the only reason we needed to have such a user-exposed knob went
away with [1], and it's been doing nothing useful since then. We don't
care if you define DC_SHA1=*, we only care that you don't ask for any
other SHA-1 implementation. If it turns out that you didn't, we'll use
sha1collisiondetection, whether you had "DC_SHA1" set or not.
As a result of this being confusing we had e.g. [2] for cmake and the
recent [3] for ci/lib.sh setting "DC_SHA1" explicitly, even though
this was always a NOOP.
A much simpler way to do this is to stop having the Makefile and
CMakeLists.txt set "DC_SHA1" to be picked up by the test-lib.sh, let's
instead add a trivial "test-tool sha1-is-sha1dc". It returns zero if
we're using sha1collisiondetection, non-zero otherwise.
1. e6b07da2780 (Makefile: make DC_SHA1 the default, 2017-03-17)
2. c4b2f41b5f5 (cmake: support for testing git with ctest, 2020-06-26)
3. 1ad5c3df35a (ci: use DC_SHA1=YesPlease on osx-clang job for CI,
2022-10-20)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-11-08 05:23:10 +08:00
|
|
|
#define platform_SHA_IS_SHA1DC /* used by "test-tool sha1-is-sha1dc" */
|
sha1: do not redefine `platform_SHA_CTX` and friends
Our in-tree SHA-1 wrappers all define platform_SHA_CTX and related
macros to point at the opaque "context" type, init, update, and similar
functions for each specific implementation.
In hash.h, we use these platform_ variables to set up the function
pointers for, e.g., the_hash_algo->init_fn(), etc.
But while these header files have a header-specific macro that prevents
them declaring their structs / functions multiple times, they
unconditionally define the platform variables, making it impossible to
load multiple SHA-1 implementations at once.
As a prerequisite for loading a separate SHA-1 implementation for
non-cryptographic uses, only define the platform_ variables if they have
not already been defined.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-26 23:22:44 +08:00
|
|
|
|
|
|
|
#ifndef platform_SHA_CTX
|
2017-05-20 19:54:28 +08:00
|
|
|
#define platform_SHA_CTX SHA1_CTX
|
2017-08-15 20:04:17 +08:00
|
|
|
#define platform_SHA1_Init git_SHA1DCInit
|
2017-05-20 19:54:28 +08:00
|
|
|
#define platform_SHA1_Update git_SHA1DCUpdate
|
|
|
|
#define platform_SHA1_Final git_SHA1DCFinal
|
sha1: do not redefine `platform_SHA_CTX` and friends
Our in-tree SHA-1 wrappers all define platform_SHA_CTX and related
macros to point at the opaque "context" type, init, update, and similar
functions for each specific implementation.
In hash.h, we use these platform_ variables to set up the function
pointers for, e.g., the_hash_algo->init_fn(), etc.
But while these header files have a header-specific macro that prevents
them declaring their structs / functions multiple times, they
unconditionally define the platform variables, making it impossible to
load multiple SHA-1 implementations at once.
As a prerequisite for loading a separate SHA-1 implementation for
non-cryptographic uses, only define the platform_ variables if they have
not already been defined.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-26 23:22:44 +08:00
|
|
|
#endif
|