2017-08-15 15:04:16 +03:00
|
|
|
#include "cache.h"
|
|
|
|
|
2017-08-15 15:04:17 +03:00
|
|
|
#ifdef DC_SHA1_EXTERNAL
|
|
|
|
/*
|
|
|
|
* Same as SHA1DCInit, but with default save_hash=0
|
|
|
|
*/
|
|
|
|
void git_SHA1DCInit(SHA1_CTX *ctx)
|
|
|
|
{
|
|
|
|
SHA1DCInit(ctx);
|
|
|
|
SHA1DCSetSafeHash(ctx, 0);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-05-20 14:54:28 +03:00
|
|
|
/*
|
2017-08-15 15:04:16 +03:00
|
|
|
* Same as SHA1DCFinal, but convert collision attack case into a verbose die().
|
2017-05-20 14:54:28 +03:00
|
|
|
*/
|
|
|
|
void git_SHA1DCFinal(unsigned char hash[20], SHA1_CTX *ctx)
|
|
|
|
{
|
|
|
|
if (!SHA1DCFinal(hash, ctx))
|
|
|
|
return;
|
|
|
|
die("SHA-1 appears to be part of a collision attack: %s",
|
hex: drop sha1_to_hex()
There's only a single caller left of sha1_to_hex(), since everybody
that has an object name in "unsigned char[]" now uses hash_to_hex()
instead.
This case is in the sha1dc wrapper, where we print a hex sha1 when
we find a collision. This one will always be sha1, regardless of the
current hash algorithm, so we can't use hash_to_hex() here. In
practice we'd probably not be running sha1 at all if it isn't the
current algorithm, but it's possible we might still occasionally
need to compute a sha1 in a post-sha256 world.
Since sha1_to_hex() is just a wrapper for hash_to_hex_algop(), let's
call that ourselves. There's value in getting rid of the sha1-specific
wrapper to de-clutter the global namespace, and to make sure nobody uses
it (and as with sha1_to_hex_r() in the previous patch, we'll drop the
coccinelle transformations, too).
The sha1_to_hex() function is mentioned in a comment; we can easily
swap that out for oid_to_hex() to give a better example. Also
update the comment that was left stale when we added "struct
object_id *" as a way to name an object and added functions to
convert it to hex.
The function is also mentioned in some test vectors in t4100, but
that's not runnable code, so there's no point in trying to clean it
up.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11 12:04:18 +03:00
|
|
|
hash_to_hex_algop(hash, &hash_algos[GIT_HASH_SHA1]));
|
2017-05-20 14:54:28 +03:00
|
|
|
}
|
|
|
|
|
2017-08-15 15:04:16 +03:00
|
|
|
/*
|
|
|
|
* Same as SHA1DCUpdate, but adjust types to match git's usual interface.
|
|
|
|
*/
|
hash algorithms: use size_t for section lengths
Continue walking the code path for the >4GB `hash-object --literally`
test to the hash algorithm step for LLP64 systems.
This patch lets the SHA1DC code use `size_t`, making it compatible with
LLP64 data models (as used e.g. by Windows).
The interested reader of this patch will note that we adjust the
signature of the `git_SHA1DCUpdate()` function without updating _any_
call site. This certainly puzzled at least one reviewer already, so here
is an explanation:
This function is never called directly, but always via the macro
`platform_SHA1_Update`, which is usually called via the macro
`git_SHA1_Update`. However, we never call `git_SHA1_Update()` directly
in `struct git_hash_algo`. Instead, we call `git_hash_sha1_update()`,
which is defined thusly:
static void git_hash_sha1_update(git_hash_ctx *ctx,
const void *data, size_t len)
{
git_SHA1_Update(&ctx->sha1, data, len);
}
i.e. it contains an implicit downcast from `size_t` to `unsigned long`
(before this here patch). With this patch, there is no downcast anymore.
With this patch, finally, the t1007-hash-object.sh "files over 4GB hash
literally" test case is fixed.
Signed-off-by: Philip Oakley <philipoakley@iee.email>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2021-11-13 00:16:51 +03:00
|
|
|
void git_SHA1DCUpdate(SHA1_CTX *ctx, const void *vdata, size_t len)
|
2017-05-20 14:54:28 +03:00
|
|
|
{
|
|
|
|
const char *data = vdata;
|
|
|
|
while (len > INT_MAX) {
|
|
|
|
SHA1DCUpdate(ctx, data, INT_MAX);
|
|
|
|
data += INT_MAX;
|
|
|
|
len -= INT_MAX;
|
|
|
|
}
|
|
|
|
SHA1DCUpdate(ctx, data, len);
|
|
|
|
}
|