All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] builtin/receive-pack: avoid generic function name hmac
Date: Tue, 5 May 2020 09:24:21 +0000	[thread overview]
Message-ID: <20200505092421.GF6530@camp.crustytoothpaste.net> (raw)
In-Reply-To: <20200505054630.5821-1-carenas@gmail.com>

[-- 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 --]

  parent reply	other threads:[~2020-05-05  9:24 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
2020-05-05  7:18   ` Carlo Marcelo Arenas Belón
2020-05-05  9:24 ` brian m. carlson [this message]
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=20200505092421.GF6530@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    /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.