Carlo Marcelo Arenas Belónfabec2c5c3 (builtin/receive-pack: switch to use the_hash_algo, 2019-08-18) renames hmac_sha1 to hmac, as it was updated to (optionally) use the hash function used by git (which won't be sha1 in the future).
hmac() is provided by NetBSD > 8 libc and conflicts as shown by :
builtin/receive-pack.c:421:13: error: conflicting types for 'hmac'
static void hmac(unsigned char *out,
^~~~
In file included from ./git-compat-util.h:172:0,
from ./builtin.h:4,
from builtin/receive-pack.c:1:
/usr/include/stdlib.h:305:10: note: previous declaration of 'hmac' was here
ssize_t hmac(const char *, const void *, size_t, const void *, size_t, void *,
^~~~While the conflict, posses the question of why are we even implementing our own RFC 2104 complaint HMAC while alternatives are readily available, the simplest solution is to make sure the name is not as generic so it would conflict with an equivalent one from the system (or linked libraries); so rename it again to hmac_hash to reflect it will use the git's defined hash function. --- builtin/receive-pack.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to builtin/receive-pack.c +2 −2
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index 2cc18bbffd..b1d939e7ed 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -418,7 +418,7 @@ static int copy_to_sideband(int in, int out, void *arg) return 0; } -static void hmac(unsigned char *out, +static void hmac_hash(unsigned char *out, const char *key_in, size_t key_len, const char *text, size_t text_len) { @@ -463,7 +463,7 @@ static char *prepare_push_cert_nonce(const char *path, timestamp_t stamp) unsigned char hash[GIT_MAX_RAWSZ]; strbuf_addf(&buf, "%s:%"PRItime, path, stamp); - hmac(hash, buf.buf, buf.len, cert_nonce_seed, strlen(cert_nonce_seed)); + hmac_hash(hash, buf.buf, buf.len, cert_nonce_seed, strlen(cert_nonce_seed)); strbuf_release(&buf); /* RFC 2104 5. HMAC-SHA1-80 */
-- 2.26.2.686.gfaf46a9ccd
