# [PATCH] builtin/receive-pack: avoid generic function name hmac 8 messages from 2020-05-05 to 2020-05-05. Participants: Carlo Marcelo Arenas Belón, Eric Sunshine, Junio C Hamano, brian m. carlson. Thread: https://gitlist.dev/t/53396 ## Carlo Marcelo Arenas Belón, 2020-05-05 05:46 Subject: [PATCH] builtin/receive-pack: avoid generic function name hmac Message-ID: <20200505054630.5821-1-carenas@gmail.com> URL: https://gitlist.dev/e/20200505054630.5821-1-carenas%40gmail.com ``` 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. --- builtin/receive-pack.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 ``` ## Eric Sunshine, 2020-05-05 05:52 Subject: Re: [PATCH] builtin/receive-pack: avoid generic function name hmac Message-ID: URL: https://gitlist.dev/e/CAPig%2BcRE60kw-PeF%3DDi7O9Kw1P1CctCX0drDzGX3diVQ2-Fu1Q%40mail.gmail.com In-Reply-To: <20200505054630.5821-1-carenas@gmail.com> ``` On Tue, May 5, 2020 at 1:46 AM Carlo Marcelo Arenas Belón wrote: > [...] > 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. > --- Missing sign-off. ``` ## Junio C Hamano, 2020-05-05 06:37 Subject: Re: [PATCH] builtin/receive-pack: avoid generic function name hmac Message-ID: URL: https://gitlist.dev/e/xmqqsggec2g1.fsf%40gitster.c.googlers.com In-Reply-To: <20200505054630.5821-1-carenas@gmail.com> ``` Carlo Marcelo Arenas Belón writes: > 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 *, > ^~~~ Including is allowed to contaminate the namespace this way? At least https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdlib.h.html does not seem to list hmac() there. > 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 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). > --- > builtin/receive-pack.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Missing sign-off. The patch text is trivially correct. > 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 */ ``` ## Carlo Marcelo Arenas Belón, 2020-05-05 07:18 Subject: Re: [PATCH] builtin/receive-pack: avoid generic function name hmac Message-ID: <20200505071834.GB1218@Carlos-MBP> URL: https://gitlist.dev/e/20200505071834.GB1218%40Carlos-MBP In-Reply-To: ``` On Mon, May 04, 2020 at 11:37:18PM -0700, Junio C Hamano wrote: > Carlo Marcelo Arenas Belón 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 > 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 ``` ## brian m. carlson, 2020-05-05 09:24 Subject: Re: [PATCH] builtin/receive-pack: avoid generic function name hmac Message-ID: <20200505092421.GF6530@camp.crustytoothpaste.net> URL: https://gitlist.dev/e/20200505092421.GF6530%40camp.crustytoothpaste.net In-Reply-To: <20200505054630.5821-1-carenas@gmail.com> ``` 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 ``` ## Carlo Marcelo Arenas Belón, 2020-05-05 09:53 Subject: [PATCH v2] builtin/receive-pack: avoid generic function name hmac() Message-ID: <20200505095326.36374-1-carenas@gmail.com> URL: https://gitlist.dev/e/20200505095326.36374-1-carenas%40gmail.com In-Reply-To: <20200505054630.5821-1-carenas@gmail.com> ``` fabec2c5c3 (builtin/receive-pack: switch to use the_hash_algo, 2019-08-18) renames hmac_sha1 to hmac, as it was updated to use the hash function used by git (which won't be sha1 in the future). hmac() is provided by NetBSD >= 8 libc and therefore 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 *, ^~~~ Rename it again to hmac_hash to reflect it will use the git's defined hash function and avoid the conflict, while at it update a comment to better describe the HMAC function that was used. Signed-off-by: Carlo Marcelo Arenas Belón --- v2 * cleaner commit message that even has an SOB builtin/receive-pack.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index 2cc18bbffd..39b0c3d70b 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,10 +463,10 @@ 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 */ + /* RFC 2104 5. HMAC-SHA1 or HMAC-SHA256 */ strbuf_addf(&buf, "%"PRItime"-%.*s", stamp, (int)the_hash_algo->hexsz, hash_to_hex(hash)); return strbuf_detach(&buf, NULL); } base-commit: af6b65d45ef179ed52087e80cb089f6b2349f4ec -- 2.26.2.686.gfaf46a9ccd ``` ## Carlo Marcelo Arenas Belón, 2020-05-05 10:12 Subject: Re: [PATCH] builtin/receive-pack: avoid generic function name hmac Message-ID: <20200505101200.GC1218@Carlos-MBP> URL: https://gitlist.dev/e/20200505101200.GC1218%40Carlos-MBP In-Reply-To: <20200505092421.GF6530@camp.crustytoothpaste.net> ``` On Tue, May 05, 2020 at 09:24:21AM +0000, brian m. carlson wrote: > 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). we define NETBSD_SOURCE since 9a695fbf38 (NetBSD compilation fix, 2009-04-26) Carlo ``` ## brian m. carlson, 2020-05-05 11:48 Subject: Re: [PATCH v2] builtin/receive-pack: avoid generic function name hmac() Message-ID: <20200505114837.GG6530@camp.crustytoothpaste.net> URL: https://gitlist.dev/e/20200505114837.GG6530%40camp.crustytoothpaste.net In-Reply-To: <20200505095326.36374-1-carenas@gmail.com> ``` On 2020-05-05 at 09:53:26, 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 use the hash function used > by git (which won't be sha1 in the future). > > hmac() is provided by NetBSD >= 8 libc and therefore 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 *, > ^~~~ > > Rename it again to hmac_hash to reflect it will use the git's defined hash > function and avoid the conflict, while at it update a comment to better > describe the HMAC function that was used. > > Signed-off-by: Carlo Marcelo Arenas Belón Looks good. Thanks again for the patch. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 ```