On 2020-05-05 at 05:46:30, Carlo Marcelo Arenas Belón wrote:
> fabec2c5c3 (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.

This is fine, although as others mentioned, there's a missing sign-off
here.  While it may seem that we can use OpenSSL's version here, we
cannot, since not all versions build with OpenSSL (for example, Debian
does not).  In fact, it's possible to build core Git without any crypto
library at all if you don't need HTTPS support.

I appreciate you pointing this out, since it was a surprise to me that
this would be in stdlib.h without further guards, although perhaps it
does have guards and we coax NetBSD to provide more than standard
functionality (as we do with glibc).
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204