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
Attachment:
signature.asc
Description: PGP signature
