All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Cc: git@vger.kernel.org, sandals@crustytoothpaste.net
Subject: Re: [PATCH] builtin/receive-pack: avoid generic function name hmac
Date: Mon, 04 May 2020 23:37:18 -0700	[thread overview]
Message-ID: <xmqqsggec2g1.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200505054630.5821-1-carenas@gmail.com> ("Carlo Marcelo Arenas =?utf-8?Q?Bel=C3=B3n=22's?= message of "Mon, 4 May 2020 22:46:30 -0700")

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

  parent reply	other threads:[~2020-05-05  6:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05  5:46 [PATCH] builtin/receive-pack: avoid generic function name hmac Carlo Marcelo Arenas Belón
2020-05-05  5:52 ` Eric Sunshine
2020-05-05  6:37 ` Junio C Hamano [this message]
2020-05-05  7:18   ` Carlo Marcelo Arenas Belón
2020-05-05  9:24 ` brian m. carlson
2020-05-05 10:12   ` Carlo Marcelo Arenas Belón
2020-05-05  9:53 ` [PATCH v2] builtin/receive-pack: avoid generic function name hmac() Carlo Marcelo Arenas Belón
2020-05-05 11:48   ` brian m. carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqsggec2g1.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.