| Message ID | 20200505054630.5821-1-carenas@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | builtin/receive-pack: avoid generic function name hmac | expand |
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.
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 */
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
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).
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
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 */
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(-)