On Mon, May 04, 2020 at 11:37:18PM -0700, Junio C Hamano wrote: > Carlo Marcelo Arenas Belón <carenas@xxxxxxxxx> 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
