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

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

[Carlo Marcelo Arenas Belón]

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

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

[Eric Sunshine]

On Tue, May 5, 2020 at 1:46 AM Carlo Marcelo Arenas Belón
<carenas@gmail.com> 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.

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

[Junio C Hamano]

Carlo Marcelo Arenas Belón  <carenas@gmail.com> 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 <stdlib.h> 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 <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).

> ---
>  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 */

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

[Carlo Marcelo Arenas Belón]

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

[PATCH v2] builtin/receive-pack: avoid generic function name hmac()

[Carlo Marcelo Arenas Belón]

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 <carenas@gmail.com>
---
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

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

[Carlo Marcelo Arenas Belón]

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

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 <carenas@gmail.com>

Looks good.  Thanks again for the patch.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]