builtin/receive-pack: avoid generic function name hmac
diff mbox series

Message ID 20200505054630.5821-1-carenas@gmail.com
State New
Headers show
Series
  • builtin/receive-pack: avoid generic function name hmac
Related show

Commit Message

Carlo Marcelo Arenas Belón May 5, 2020, 5:46 a.m. UTC
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(-)

Comments

Eric Sunshine May 5, 2020, 5:52 a.m. UTC | #1
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.
Junio C Hamano May 5, 2020, 6:37 a.m. UTC | #2
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 */
Carlo Marcelo Arenas Belón May 5, 2020, 7:18 a.m. UTC | #3
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
brian m. carlson May 5, 2020, 9:24 a.m. UTC | #4
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).
Carlo Marcelo Arenas Belón May 5, 2020, 10:12 a.m. UTC | #5
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

Patch
diff mbox series

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