Re: [PATCH] builtin/receive-pack: avoid generic function name hmac

["Carlo Marcelo Arenas Belón" <carenas@gmail.com>]

On Mon, May 04, 2020 at 11:37:18PM -0700, Junio C Hamano wrote:
> Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:
> > 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.
> 
> I do not mind renaming ours, as it is harder to get the <stdlib.h>
> fixed on the NetBSD, but I would phrase s/equivalent/unrelated/ (or
> even "irrelevant"), as it is clearly not an "alternative" that is
> readily available outside NetBSD.  Otherwise we would have found
> this a lot sooner (it used to be called hmac_sha1() and renamed to
> hmac() in August last year).

fair enough, would probably better drop this paragraph; but I wasn't
referring to hmac() in NetBSD, but the fact that we are linking against
OpenSSL (or their equivalent in macOS and Windows) that provide HMAC,
and even using it (but with MD5) already for git-imap-send.

the SHA256 feature will even bring (alternatively) libgcrypt to the mix
so it seemed strange that we didn't abstract this hmac function as part
of that interface instead since we seemed to have plenty of alternatives
to chose from and would had make IMHO more sense as a fallback inside
there.

Carlo