* [PATCH] hash: Allow building with the external sha1dc library @ 2017-07-25 5:57 Takashi Iwai 2017-07-25 19:06 ` Junio C Hamano 2017-07-28 15:58 ` Ævar Arnfjörð Bjarmason 0 siblings, 2 replies; 13+ messages in thread From: Takashi Iwai @ 2017-07-25 5:57 UTC (permalink / raw) To: git; +Cc: Andreas Stieger Some distros provide SHA1 collision detect code as a shared library. It's the very same code as we have in git tree, and git can link with it as well; at least, it may make maintenance easier, according to our security guys. This patch allows user to build git linking with the external sha1dc library instead of the built-in sha1dc code. User needs to define DC_SHA1_EXTERNAL explicitly. As default, the built-in sha1dc code is used like before. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- Makefile | 12 ++++++++++++ hash.h | 4 +++- sha1dc_git_ext.c | 11 +++++++++++ sha1dc_git_ext.h | 25 +++++++++++++++++++++++++ 4 files changed, 51 insertions(+), 1 deletion(-) create mode 100644 sha1dc_git_ext.c create mode 100644 sha1dc_git_ext.h diff --git a/Makefile b/Makefile index 461c845d33cb..f1a262d56254 100644 --- a/Makefile +++ b/Makefile @@ -162,6 +162,12 @@ all:: # algorithm. This is slower, but may detect attempted collision attacks. # Takes priority over other *_SHA1 knobs. # +# Define DC_SHA1_EXTERNAL in addition to DC_SHA1 if you want to build / link +# git with the external sha1collisiondetection library. +# Without this option, i.e. the default behavior is to build git with its +# own sha1dc code. If any extra linker option is required, define them in +# DC_SHA1_LINK variable in addition. +# # Define DC_SHA1_SUBMODULE in addition to DC_SHA1 to use the # sha1collisiondetection shipped as a submodule instead of the # non-submodule copy in sha1dc/. This is an experimental option used @@ -1472,6 +1478,11 @@ ifdef APPLE_COMMON_CRYPTO BASIC_CFLAGS += -DSHA1_APPLE else DC_SHA1 := YesPlease +ifdef DC_SHA1_EXTERNAL + LIB_OBJS += sha1dc_git_ext.o + BASIC_CFLAGS += -DSHA1_DC -DDC_SHA1_EXTERNAL + EXTLIBS += $(DC_SHA1_LINK) -lsha1detectcoll +else ifdef DC_SHA1_SUBMODULE LIB_OBJS += sha1collisiondetection/lib/sha1.o LIB_OBJS += sha1collisiondetection/lib/ubc_check.o @@ -1492,6 +1503,7 @@ endif endif endif endif +endif ifdef SHA1_MAX_BLOCK_SIZE LIB_OBJS += compat/sha1-chunked.o diff --git a/hash.h b/hash.h index bef3e630a093..dce327d58d07 100644 --- a/hash.h +++ b/hash.h @@ -8,7 +8,9 @@ #elif defined(SHA1_OPENSSL) #include <openssl/sha.h> #elif defined(SHA1_DC) -#ifdef DC_SHA1_SUBMODULE +#if defined(DC_SHA1_EXTERNAL) +#include "sha1dc_git_ext.h" +#elif defined(DC_SHA1_SUBMODULE) #include "sha1collisiondetection/lib/sha1.h" #else #include "sha1dc/sha1.h" diff --git a/sha1dc_git_ext.c b/sha1dc_git_ext.c new file mode 100644 index 000000000000..359439fc3d93 --- /dev/null +++ b/sha1dc_git_ext.c @@ -0,0 +1,11 @@ +/* Only for DC_SHA1_EXTERNAL; sharing the same hooks as built-in sha1dc */ + +#include "cache.h" +#include <sha1.h> +#include "sha1dc_git.c" + +void git_SHA1DCInit(SHA1_CTX *ctx) +{ + SHA1DCInit(ctx); + SHA1DCSetSafeHash(ctx, 0); +} diff --git a/sha1dc_git_ext.h b/sha1dc_git_ext.h new file mode 100644 index 000000000000..d0ea8ce518db --- /dev/null +++ b/sha1dc_git_ext.h @@ -0,0 +1,25 @@ +/* + * This file is included by hash.h for DC_SHA1_EXTERNAL + */ + +#include <sha1.h> + +/* + * Same as SHA1DCInit, but with default save_hash=0 + */ +void git_SHA1DCInit(SHA1_CTX *); + +/* + * Same as SHA1DCFinal, but convert collision attack case into a verbose die(). + */ +void git_SHA1DCFinal(unsigned char [20], SHA1_CTX *); + +/* + * Same as SHA1DCUpdate, but adjust types to match git's usual interface. + */ +void git_SHA1DCUpdate(SHA1_CTX *ctx, const void *data, unsigned long len); + +#define platform_SHA_CTX SHA1_CTX +#define platform_SHA1_Init git_SHA1DCInit +#define platform_SHA1_Update git_SHA1DCUpdate +#define platform_SHA1_Final git_SHA1DCFinal -- 2.13.3 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-07-25 5:57 [PATCH] hash: Allow building with the external sha1dc library Takashi Iwai @ 2017-07-25 19:06 ` Junio C Hamano 2017-07-28 15:58 ` Ævar Arnfjörð Bjarmason 1 sibling, 0 replies; 13+ messages in thread From: Junio C Hamano @ 2017-07-25 19:06 UTC (permalink / raw) To: Takashi Iwai; +Cc: git, Andreas Stieger Takashi Iwai <tiwai@suse.de> writes: > Some distros provide SHA1 collision detect code as a shared library. > It's the very same code as we have in git tree, and git can link with > it as well; at least, it may make maintenance easier, according to our > security guys. > > This patch allows user to build git linking with the external sha1dc > library instead of the built-in sha1dc code. User needs to define > DC_SHA1_EXTERNAL explicitly. As default, the built-in sha1dc code is > used like before. > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- I do not have such an environment to test this patch, but it looks like a very sensible thing to do. Will queue; thanks. > Makefile | 12 ++++++++++++ > hash.h | 4 +++- > sha1dc_git_ext.c | 11 +++++++++++ > sha1dc_git_ext.h | 25 +++++++++++++++++++++++++ > 4 files changed, 51 insertions(+), 1 deletion(-) > create mode 100644 sha1dc_git_ext.c > create mode 100644 sha1dc_git_ext.h > > diff --git a/Makefile b/Makefile > index 461c845d33cb..f1a262d56254 100644 > --- a/Makefile > +++ b/Makefile > @@ -162,6 +162,12 @@ all:: > # algorithm. This is slower, but may detect attempted collision attacks. > # Takes priority over other *_SHA1 knobs. > # > +# Define DC_SHA1_EXTERNAL in addition to DC_SHA1 if you want to build / link > +# git with the external sha1collisiondetection library. > +# Without this option, i.e. the default behavior is to build git with its > +# own sha1dc code. If any extra linker option is required, define them in > +# DC_SHA1_LINK variable in addition. > +# > # Define DC_SHA1_SUBMODULE in addition to DC_SHA1 to use the > # sha1collisiondetection shipped as a submodule instead of the > # non-submodule copy in sha1dc/. This is an experimental option used > @@ -1472,6 +1478,11 @@ ifdef APPLE_COMMON_CRYPTO > BASIC_CFLAGS += -DSHA1_APPLE > else > DC_SHA1 := YesPlease > +ifdef DC_SHA1_EXTERNAL > + LIB_OBJS += sha1dc_git_ext.o > + BASIC_CFLAGS += -DSHA1_DC -DDC_SHA1_EXTERNAL > + EXTLIBS += $(DC_SHA1_LINK) -lsha1detectcoll > +else > ifdef DC_SHA1_SUBMODULE > LIB_OBJS += sha1collisiondetection/lib/sha1.o > LIB_OBJS += sha1collisiondetection/lib/ubc_check.o > @@ -1492,6 +1503,7 @@ endif > endif > endif > endif > +endif > > ifdef SHA1_MAX_BLOCK_SIZE > LIB_OBJS += compat/sha1-chunked.o > diff --git a/hash.h b/hash.h > index bef3e630a093..dce327d58d07 100644 > --- a/hash.h > +++ b/hash.h > @@ -8,7 +8,9 @@ > #elif defined(SHA1_OPENSSL) > #include <openssl/sha.h> > #elif defined(SHA1_DC) > -#ifdef DC_SHA1_SUBMODULE > +#if defined(DC_SHA1_EXTERNAL) > +#include "sha1dc_git_ext.h" > +#elif defined(DC_SHA1_SUBMODULE) > #include "sha1collisiondetection/lib/sha1.h" > #else > #include "sha1dc/sha1.h" > diff --git a/sha1dc_git_ext.c b/sha1dc_git_ext.c > new file mode 100644 > index 000000000000..359439fc3d93 > --- /dev/null > +++ b/sha1dc_git_ext.c > @@ -0,0 +1,11 @@ > +/* Only for DC_SHA1_EXTERNAL; sharing the same hooks as built-in sha1dc */ > + > +#include "cache.h" > +#include <sha1.h> > +#include "sha1dc_git.c" > + > +void git_SHA1DCInit(SHA1_CTX *ctx) > +{ > + SHA1DCInit(ctx); > + SHA1DCSetSafeHash(ctx, 0); > +} > diff --git a/sha1dc_git_ext.h b/sha1dc_git_ext.h > new file mode 100644 > index 000000000000..d0ea8ce518db > --- /dev/null > +++ b/sha1dc_git_ext.h > @@ -0,0 +1,25 @@ > +/* > + * This file is included by hash.h for DC_SHA1_EXTERNAL > + */ > + > +#include <sha1.h> > + > +/* > + * Same as SHA1DCInit, but with default save_hash=0 > + */ > +void git_SHA1DCInit(SHA1_CTX *); > + > +/* > + * Same as SHA1DCFinal, but convert collision attack case into a verbose die(). > + */ > +void git_SHA1DCFinal(unsigned char [20], SHA1_CTX *); > + > +/* > + * Same as SHA1DCUpdate, but adjust types to match git's usual interface. > + */ > +void git_SHA1DCUpdate(SHA1_CTX *ctx, const void *data, unsigned long len); > + > +#define platform_SHA_CTX SHA1_CTX > +#define platform_SHA1_Init git_SHA1DCInit > +#define platform_SHA1_Update git_SHA1DCUpdate > +#define platform_SHA1_Final git_SHA1DCFinal ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-07-25 5:57 [PATCH] hash: Allow building with the external sha1dc library Takashi Iwai 2017-07-25 19:06 ` Junio C Hamano @ 2017-07-28 15:58 ` Ævar Arnfjörð Bjarmason 2017-07-28 16:04 ` Ævar Arnfjörð Bjarmason 2017-08-01 5:46 ` Takashi Iwai 1 sibling, 2 replies; 13+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-07-28 15:58 UTC (permalink / raw) To: Takashi Iwai; +Cc: Git Mailing List, Andreas Stieger On Tue, Jul 25, 2017 at 7:57 AM, Takashi Iwai <tiwai@suse.de> wrote: > Some distros provide SHA1 collision detect code as a shared library. > It's the very same code as we have in git tree, and git can link with > it as well; at least, it may make maintenance easier, according to our > security guys. > > This patch allows user to build git linking with the external sha1dc > library instead of the built-in sha1dc code. User needs to define > DC_SHA1_EXTERNAL explicitly. As default, the built-in sha1dc code is > used like before. This whole thing sounds sensible. I reviewed this (but like Junio haven't tested it with a lib) and I think it would be worth noting the following in the commit message / Makefile documentation: * The "sha1detectcoll" *.so name for the "sha1collisiondetection" library is not something you or suse presumably) made up, it's a name the sha1collisiondetection.git itself creates for its library. I think the Makefile docs you've added here are a bit confusing, you talk about the "external sha1collisiondetection library" but then link against sha1detectcoll". It's worth calling out this difference in the docs IMO. I.e. not talk about the sha1detectcoll.so library form of sha1collisiondetection, not the sha1collisiondetection project name as a library. * It might be worth noting that this is *not* linking against the same code we ship ourselves due to the difference in defining SHA1DC_INIT_SAFE_HASH_DEFAULT for the git project's needs in the one we build, hence your need to have a git_SHA1DCInit() wrapper whereas we call SHA1DCInit() directly. It might be interesting to note that the library version will always be *slightly* slower (although the difference will be trivial). * Nothing in your commit message or docs explains why DC_SHA1_LINK is needed. We don't have these sorts of variables for other external libraries we link to, why the difference? Some other things I observed: * We now have much of the same header code copy/pasted between sha1dc_git.h and sha1dc_git_ext.h, did you consider just always including the former but making what it's doing conditional on DC_SHA1_EXTERNAL? I don't know if it would be worth it from a cursory glance, but again your commit message doesn't list that among options considered & discarded. * I think it makes sense to spew out a "not both!" error in the Makefile if you set DC_SHA1_EXTERNAL=Y and DC_SHA1_SUBMODULE=Y. See my 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) for an example of how to do this. * The whole business of "#include <sha1.h>" looks very fragile, are there really no other packages in e.g. suse that ship a sha1.h? Debian has libmd-dev that ships /usr/include/sha1.h that conflicts with this: https://packages.debian.org/search?searchon=contents&keywords=sha1.h&mode=exactfilename&suite=unstable&arch=any Shipping a sha1.h as opposed to a sha1collisiondetection.h or sha1detectcoll.h or whatever seems like a *really* bad decision by upstream that should be the subject of at least seeing if they'll take a pull request to fix it before you package it or before we include something that'll probably need to be fixed / worked around anyway in Git. > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > Makefile | 12 ++++++++++++ > hash.h | 4 +++- > sha1dc_git_ext.c | 11 +++++++++++ > sha1dc_git_ext.h | 25 +++++++++++++++++++++++++ > 4 files changed, 51 insertions(+), 1 deletion(-) > create mode 100644 sha1dc_git_ext.c > create mode 100644 sha1dc_git_ext.h > > diff --git a/Makefile b/Makefile > index 461c845d33cb..f1a262d56254 100644 > --- a/Makefile > +++ b/Makefile > @@ -162,6 +162,12 @@ all:: > # algorithm. This is slower, but may detect attempted collision attacks. > # Takes priority over other *_SHA1 knobs. > # > +# Define DC_SHA1_EXTERNAL in addition to DC_SHA1 if you want to build / link > +# git with the external sha1collisiondetection library. > +# Without this option, i.e. the default behavior is to build git with its > +# own sha1dc code. If any extra linker option is required, define them in > +# DC_SHA1_LINK variable in addition. > +# > # Define DC_SHA1_SUBMODULE in addition to DC_SHA1 to use the > # sha1collisiondetection shipped as a submodule instead of the > # non-submodule copy in sha1dc/. This is an experimental option used > @@ -1472,6 +1478,11 @@ ifdef APPLE_COMMON_CRYPTO > BASIC_CFLAGS += -DSHA1_APPLE > else > DC_SHA1 := YesPlease > +ifdef DC_SHA1_EXTERNAL > + LIB_OBJS += sha1dc_git_ext.o > + BASIC_CFLAGS += -DSHA1_DC -DDC_SHA1_EXTERNAL > + EXTLIBS += $(DC_SHA1_LINK) -lsha1detectcoll > +else > ifdef DC_SHA1_SUBMODULE > LIB_OBJS += sha1collisiondetection/lib/sha1.o > LIB_OBJS += sha1collisiondetection/lib/ubc_check.o > @@ -1492,6 +1503,7 @@ endif > endif > endif > endif > +endif > > ifdef SHA1_MAX_BLOCK_SIZE > LIB_OBJS += compat/sha1-chunked.o > diff --git a/hash.h b/hash.h > index bef3e630a093..dce327d58d07 100644 > --- a/hash.h > +++ b/hash.h > @@ -8,7 +8,9 @@ > #elif defined(SHA1_OPENSSL) > #include <openssl/sha.h> > #elif defined(SHA1_DC) > -#ifdef DC_SHA1_SUBMODULE > +#if defined(DC_SHA1_EXTERNAL) > +#include "sha1dc_git_ext.h" > +#elif defined(DC_SHA1_SUBMODULE) > #include "sha1collisiondetection/lib/sha1.h" > #else > #include "sha1dc/sha1.h" > diff --git a/sha1dc_git_ext.c b/sha1dc_git_ext.c > new file mode 100644 > index 000000000000..359439fc3d93 > --- /dev/null > +++ b/sha1dc_git_ext.c > @@ -0,0 +1,11 @@ > +/* Only for DC_SHA1_EXTERNAL; sharing the same hooks as built-in sha1dc */ > + > +#include "cache.h" > +#include <sha1.h> > +#include "sha1dc_git.c" > + > +void git_SHA1DCInit(SHA1_CTX *ctx) > +{ > + SHA1DCInit(ctx); > + SHA1DCSetSafeHash(ctx, 0); > +} > diff --git a/sha1dc_git_ext.h b/sha1dc_git_ext.h > new file mode 100644 > index 000000000000..d0ea8ce518db > --- /dev/null > +++ b/sha1dc_git_ext.h > @@ -0,0 +1,25 @@ > +/* > + * This file is included by hash.h for DC_SHA1_EXTERNAL > + */ > + > +#include <sha1.h> > + > +/* > + * Same as SHA1DCInit, but with default save_hash=0 > + */ > +void git_SHA1DCInit(SHA1_CTX *); > + > +/* > + * Same as SHA1DCFinal, but convert collision attack case into a verbose die(). > + */ > +void git_SHA1DCFinal(unsigned char [20], SHA1_CTX *); > + > +/* > + * Same as SHA1DCUpdate, but adjust types to match git's usual interface. > + */ > +void git_SHA1DCUpdate(SHA1_CTX *ctx, const void *data, unsigned long len); > + > +#define platform_SHA_CTX SHA1_CTX > +#define platform_SHA1_Init git_SHA1DCInit > +#define platform_SHA1_Update git_SHA1DCUpdate > +#define platform_SHA1_Final git_SHA1DCFinal > -- > 2.13.3 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-07-28 15:58 ` Ævar Arnfjörð Bjarmason @ 2017-07-28 16:04 ` Ævar Arnfjörð Bjarmason 2017-07-31 22:28 ` Junio C Hamano ` (2 more replies) 2017-08-01 5:46 ` Takashi Iwai 1 sibling, 3 replies; 13+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-07-28 16:04 UTC (permalink / raw) To: Takashi Iwai; +Cc: Git Mailing List, Andreas Stieger On Fri, Jul 28, 2017 at 5:58 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > On Tue, Jul 25, 2017 at 7:57 AM, Takashi Iwai <tiwai@suse.de> wrote: >> Some distros provide SHA1 collision detect code as a shared library. >> It's the very same code as we have in git tree, and git can link with >> it as well; at least, it may make maintenance easier, according to our >> security guys. >> >> This patch allows user to build git linking with the external sha1dc >> library instead of the built-in sha1dc code. User needs to define >> DC_SHA1_EXTERNAL explicitly. As default, the built-in sha1dc code is >> used like before. > > This whole thing sounds sensible. I reviewed this (but like Junio > haven't tested it with a lib) and I think it would be worth noting the > following in the commit message / Makefile documentation: > > * The "sha1detectcoll" *.so name for the "sha1collisiondetection" > library is not something you or suse presumably) made up, it's a name > the sha1collisiondetection.git itself creates for its library. I think > the Makefile docs you've added here are a bit confusing, you talk > about the "external sha1collisiondetection library" but then link > against sha1detectcoll". It's worth calling out this difference in the > docs IMO. I.e. not talk about the sha1detectcoll.so library form of > sha1collisiondetection, not the sha1collisiondetection project name as > a library. > > * It might be worth noting that this is *not* linking against the same > code we ship ourselves due to the difference in defining > SHA1DC_INIT_SAFE_HASH_DEFAULT for the git project's needs in the one > we build, hence your need to have a git_SHA1DCInit() wrapper whereas > we call SHA1DCInit() directly. It might be interesting to note that > the library version will always be *slightly* slower (although the > difference will be trivial). > > * Nothing in your commit message or docs explains why DC_SHA1_LINK is > needed. We don't have these sorts of variables for other external > libraries we link to, why the difference? > > Some other things I observed: > > * We now have much of the same header code copy/pasted between > sha1dc_git.h and sha1dc_git_ext.h, did you consider just always > including the former but making what it's doing conditional on > DC_SHA1_EXTERNAL? I don't know if it would be worth it from a cursory > glance, but again your commit message doesn't list that among options > considered & discarded. > > * I think it makes sense to spew out a "not both!" error in the > Makefile if you set DC_SHA1_EXTERNAL=Y and DC_SHA1_SUBMODULE=Y. See my > 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) for an > example of how to do this. > > * The whole business of "#include <sha1.h>" looks very fragile, are > there really no other packages in e.g. suse that ship a sha1.h? Debian > has libmd-dev that ships /usr/include/sha1.h that conflicts with this: > https://packages.debian.org/search?searchon=contents&keywords=sha1.h&mode=exactfilename&suite=unstable&arch=any > > Shipping a sha1.h as opposed to a sha1collisiondetection.h or > sha1detectcoll.h or whatever seems like a *really* bad decision by > upstream that should be the subject of at least seeing if they'll take > a pull request to fix it before you package it or before we include > something that'll probably need to be fixed / worked around anyway in > Git. I sent this last bit a tad too soon in a checkout of sha1collisiondetection.git: $ make PREFIX=/tmp/local install >/dev/null 2>&1 && find /tmp/local/ -type f /tmp/local/include/sha1dc/sha1.h /tmp/local/bin/sha1dcsum /tmp/local/bin/sha1dcsum_partialcoll /tmp/local/lib/libsha1detectcoll.a /tmp/local/lib/libsha1detectcoll.so.1.0.0 /tmp/local/lib/libsha1detectcoll.la So the upstream library expects you (and it's documented in their README) to do: #include <sha1dc/sha1.h> But your patch is just doing: #include <sha1.h> At best this seems like a trivial bug and at worst us encoding some Suse-specific packaging convention in git, since other distros would presumably want to package this in /usr/include/sha1dc/sha1.h as upstream suggests. I.e. using the ambiguous sha1.h name is not something upstream's doing by default, it's something you're doing in your package. >> Signed-off-by: Takashi Iwai <tiwai@suse.de> >> --- >> Makefile | 12 ++++++++++++ >> hash.h | 4 +++- >> sha1dc_git_ext.c | 11 +++++++++++ >> sha1dc_git_ext.h | 25 +++++++++++++++++++++++++ >> 4 files changed, 51 insertions(+), 1 deletion(-) >> create mode 100644 sha1dc_git_ext.c >> create mode 100644 sha1dc_git_ext.h >> >> diff --git a/Makefile b/Makefile >> index 461c845d33cb..f1a262d56254 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -162,6 +162,12 @@ all:: >> # algorithm. This is slower, but may detect attempted collision attacks. >> # Takes priority over other *_SHA1 knobs. >> # >> +# Define DC_SHA1_EXTERNAL in addition to DC_SHA1 if you want to build / link >> +# git with the external sha1collisiondetection library. >> +# Without this option, i.e. the default behavior is to build git with its >> +# own sha1dc code. If any extra linker option is required, define them in >> +# DC_SHA1_LINK variable in addition. >> +# >> # Define DC_SHA1_SUBMODULE in addition to DC_SHA1 to use the >> # sha1collisiondetection shipped as a submodule instead of the >> # non-submodule copy in sha1dc/. This is an experimental option used >> @@ -1472,6 +1478,11 @@ ifdef APPLE_COMMON_CRYPTO >> BASIC_CFLAGS += -DSHA1_APPLE >> else >> DC_SHA1 := YesPlease >> +ifdef DC_SHA1_EXTERNAL >> + LIB_OBJS += sha1dc_git_ext.o >> + BASIC_CFLAGS += -DSHA1_DC -DDC_SHA1_EXTERNAL >> + EXTLIBS += $(DC_SHA1_LINK) -lsha1detectcoll >> +else >> ifdef DC_SHA1_SUBMODULE >> LIB_OBJS += sha1collisiondetection/lib/sha1.o >> LIB_OBJS += sha1collisiondetection/lib/ubc_check.o >> @@ -1492,6 +1503,7 @@ endif >> endif >> endif >> endif >> +endif >> >> ifdef SHA1_MAX_BLOCK_SIZE >> LIB_OBJS += compat/sha1-chunked.o >> diff --git a/hash.h b/hash.h >> index bef3e630a093..dce327d58d07 100644 >> --- a/hash.h >> +++ b/hash.h >> @@ -8,7 +8,9 @@ >> #elif defined(SHA1_OPENSSL) >> #include <openssl/sha.h> >> #elif defined(SHA1_DC) >> -#ifdef DC_SHA1_SUBMODULE >> +#if defined(DC_SHA1_EXTERNAL) >> +#include "sha1dc_git_ext.h" >> +#elif defined(DC_SHA1_SUBMODULE) >> #include "sha1collisiondetection/lib/sha1.h" >> #else >> #include "sha1dc/sha1.h" >> diff --git a/sha1dc_git_ext.c b/sha1dc_git_ext.c >> new file mode 100644 >> index 000000000000..359439fc3d93 >> --- /dev/null >> +++ b/sha1dc_git_ext.c >> @@ -0,0 +1,11 @@ >> +/* Only for DC_SHA1_EXTERNAL; sharing the same hooks as built-in sha1dc */ >> + >> +#include "cache.h" >> +#include <sha1.h> >> +#include "sha1dc_git.c" >> + >> +void git_SHA1DCInit(SHA1_CTX *ctx) >> +{ >> + SHA1DCInit(ctx); >> + SHA1DCSetSafeHash(ctx, 0); >> +} > > > >> diff --git a/sha1dc_git_ext.h b/sha1dc_git_ext.h >> new file mode 100644 >> index 000000000000..d0ea8ce518db >> --- /dev/null >> +++ b/sha1dc_git_ext.h >> @@ -0,0 +1,25 @@ >> +/* >> + * This file is included by hash.h for DC_SHA1_EXTERNAL >> + */ >> + >> +#include <sha1.h> >> + >> +/* >> + * Same as SHA1DCInit, but with default save_hash=0 >> + */ >> +void git_SHA1DCInit(SHA1_CTX *); >> + >> +/* >> + * Same as SHA1DCFinal, but convert collision attack case into a verbose die(). >> + */ >> +void git_SHA1DCFinal(unsigned char [20], SHA1_CTX *); >> + >> +/* >> + * Same as SHA1DCUpdate, but adjust types to match git's usual interface. >> + */ >> +void git_SHA1DCUpdate(SHA1_CTX *ctx, const void *data, unsigned long len); >> + >> +#define platform_SHA_CTX SHA1_CTX >> +#define platform_SHA1_Init git_SHA1DCInit >> +#define platform_SHA1_Update git_SHA1DCUpdate >> +#define platform_SHA1_Final git_SHA1DCFinal >> -- >> 2.13.3 >> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-07-28 16:04 ` Ævar Arnfjörð Bjarmason @ 2017-07-31 22:28 ` Junio C Hamano 2017-08-01 5:52 ` Takashi Iwai 2017-08-12 0:42 ` Junio C Hamano 2 siblings, 0 replies; 13+ messages in thread From: Junio C Hamano @ 2017-07-31 22:28 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Takashi Iwai, Git Mailing List, Andreas Stieger Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > So the upstream library expects you (and it's documented in their README) to do: > > #include <sha1dc/sha1.h> > > But your patch is just doing: > > #include <sha1.h> > > At best this seems like a trivial bug and at worst us encoding some > Suse-specific packaging convention in git, since other distros would > presumably want to package this in /usr/include/sha1dc/sha1.h as > upstream suggests. I.e. using the ambiguous sha1.h name is not > something upstream's doing by default, it's something you're doing in > your package. It seems there still needs a bit more work on this patch. Thanks for reviewing and pointing out what needs to be addressed. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-07-28 16:04 ` Ævar Arnfjörð Bjarmason 2017-07-31 22:28 ` Junio C Hamano @ 2017-08-01 5:52 ` Takashi Iwai 2017-08-12 0:42 ` Junio C Hamano 2 siblings, 0 replies; 13+ messages in thread From: Takashi Iwai @ 2017-08-01 5:52 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List, Andreas Stieger On Fri, 28 Jul 2017 18:04:18 +0200, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jul 28, 2017 at 5:58 PM, Ævar Arnfjörð Bjarmason > <avarab@gmail.com> wrote: > > On Tue, Jul 25, 2017 at 7:57 AM, Takashi Iwai <tiwai@suse.de> wrote: > >> Some distros provide SHA1 collision detect code as a shared library. > >> It's the very same code as we have in git tree, and git can link with > >> it as well; at least, it may make maintenance easier, according to our > >> security guys. > >> > >> This patch allows user to build git linking with the external sha1dc > >> library instead of the built-in sha1dc code. User needs to define > >> DC_SHA1_EXTERNAL explicitly. As default, the built-in sha1dc code is > >> used like before. > > > > This whole thing sounds sensible. I reviewed this (but like Junio > > haven't tested it with a lib) and I think it would be worth noting the > > following in the commit message / Makefile documentation: > > > > * The "sha1detectcoll" *.so name for the "sha1collisiondetection" > > library is not something you or suse presumably) made up, it's a name > > the sha1collisiondetection.git itself creates for its library. I think > > the Makefile docs you've added here are a bit confusing, you talk > > about the "external sha1collisiondetection library" but then link > > against sha1detectcoll". It's worth calling out this difference in the > > docs IMO. I.e. not talk about the sha1detectcoll.so library form of > > sha1collisiondetection, not the sha1collisiondetection project name as > > a library. > > > > * It might be worth noting that this is *not* linking against the same > > code we ship ourselves due to the difference in defining > > SHA1DC_INIT_SAFE_HASH_DEFAULT for the git project's needs in the one > > we build, hence your need to have a git_SHA1DCInit() wrapper whereas > > we call SHA1DCInit() directly. It might be interesting to note that > > the library version will always be *slightly* slower (although the > > difference will be trivial). > > > > * Nothing in your commit message or docs explains why DC_SHA1_LINK is > > needed. We don't have these sorts of variables for other external > > libraries we link to, why the difference? > > > > Some other things I observed: > > > > * We now have much of the same header code copy/pasted between > > sha1dc_git.h and sha1dc_git_ext.h, did you consider just always > > including the former but making what it's doing conditional on > > DC_SHA1_EXTERNAL? I don't know if it would be worth it from a cursory > > glance, but again your commit message doesn't list that among options > > considered & discarded. > > > > * I think it makes sense to spew out a "not both!" error in the > > Makefile if you set DC_SHA1_EXTERNAL=Y and DC_SHA1_SUBMODULE=Y. See my > > 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) for an > > example of how to do this. > > > > * The whole business of "#include <sha1.h>" looks very fragile, are > > there really no other packages in e.g. suse that ship a sha1.h? Debian > > has libmd-dev that ships /usr/include/sha1.h that conflicts with this: > > https://packages.debian.org/search?searchon=contents&keywords=sha1.h&mode=exactfilename&suite=unstable&arch=any > > > > Shipping a sha1.h as opposed to a sha1collisiondetection.h or > > sha1detectcoll.h or whatever seems like a *really* bad decision by > > upstream that should be the subject of at least seeing if they'll take > > a pull request to fix it before you package it or before we include > > something that'll probably need to be fixed / worked around anyway in > > Git. > > I sent this last bit a tad too soon in a checkout of sha1collisiondetection.git: > > $ make PREFIX=/tmp/local install >/dev/null 2>&1 && find /tmp/local/ -type f > /tmp/local/include/sha1dc/sha1.h > /tmp/local/bin/sha1dcsum > /tmp/local/bin/sha1dcsum_partialcoll > /tmp/local/lib/libsha1detectcoll.a > /tmp/local/lib/libsha1detectcoll.so.1.0.0 > /tmp/local/lib/libsha1detectcoll.la > > So the upstream library expects you (and it's documented in their README) to do: > > #include <sha1dc/sha1.h> > > But your patch is just doing: > > #include <sha1.h> > > At best this seems like a trivial bug and at worst us encoding some > Suse-specific packaging convention in git, since other distros would > presumably want to package this in /usr/include/sha1dc/sha1.h as > upstream suggests. I.e. using the ambiguous sha1.h name is not > something upstream's doing by default, it's something you're doing in > your package. Actually it seems to be a wrong usage of $INCLUDEDIR in the upstream Makefile, and SUSE package blindly override $INCLUDEDIR. But sha1dc/sha1.h looks like the correct path, as README.md mentions, indeed, so maybe we need to work around in SUSE package side. Andreas, could you work on it please? thanks, Takashi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-07-28 16:04 ` Ævar Arnfjörð Bjarmason 2017-07-31 22:28 ` Junio C Hamano 2017-08-01 5:52 ` Takashi Iwai @ 2017-08-12 0:42 ` Junio C Hamano 2017-08-12 6:50 ` Takashi Iwai 2 siblings, 1 reply; 13+ messages in thread From: Junio C Hamano @ 2017-08-12 0:42 UTC (permalink / raw) To: Takashi Iwai, Ævar Arnfjörð Bjarmason Cc: Git Mailing List, Andreas Stieger Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > On Fri, Jul 28, 2017 at 5:58 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > I sent this last bit a tad too soon in a checkout of sha1collisiondetection.git: > > $ make PREFIX=/tmp/local install >/dev/null 2>&1 && find /tmp/local/ -type f > /tmp/local/include/sha1dc/sha1.h > /tmp/local/bin/sha1dcsum > /tmp/local/bin/sha1dcsum_partialcoll > /tmp/local/lib/libsha1detectcoll.a > /tmp/local/lib/libsha1detectcoll.so.1.0.0 > /tmp/local/lib/libsha1detectcoll.la > > So the upstream library expects you (and it's documented in their README) to do: > > #include <sha1dc/sha1.h> > > But your patch is just doing: > > #include <sha1.h> > > At best this seems like a trivial bug and at worst us encoding some > Suse-specific packaging convention in git, since other distros would > presumably want to package this in /usr/include/sha1dc/sha1.h as > upstream suggests. I.e. using the ambiguous sha1.h name is not > something upstream's doing by default, it's something you're doing in > your package. I do not think I saw any updates to this thread. Should I consider the topic ti/external-sha1dc now abandoned? As we have finished Git 2.14 cycle, in preparation for the next one, the 'next' branch will be rewound and rebuilt early next week. I do not mind tentatively ejecting some topics that needs fix-ups out of 'next' to give them a clean restart. If there will be a reroll that addresses the concerns raised during the discussion, please let me know. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-08-12 0:42 ` Junio C Hamano @ 2017-08-12 6:50 ` Takashi Iwai 0 siblings, 0 replies; 13+ messages in thread From: Takashi Iwai @ 2017-08-12 6:50 UTC (permalink / raw) To: Junio C Hamano Cc: Ævar Arnfjörð Bjarmason, Git Mailing List, Andreas Stieger On Sat, 12 Aug 2017 02:42:25 +0200, Junio C Hamano wrote: > > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > > > On Fri, Jul 28, 2017 at 5:58 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > > > I sent this last bit a tad too soon in a checkout of sha1collisiondetection.git: > > > > $ make PREFIX=/tmp/local install >/dev/null 2>&1 && find /tmp/local/ -type f > > /tmp/local/include/sha1dc/sha1.h > > /tmp/local/bin/sha1dcsum > > /tmp/local/bin/sha1dcsum_partialcoll > > /tmp/local/lib/libsha1detectcoll.a > > /tmp/local/lib/libsha1detectcoll.so.1.0.0 > > /tmp/local/lib/libsha1detectcoll.la > > > > So the upstream library expects you (and it's documented in their README) to do: > > > > #include <sha1dc/sha1.h> > > > > But your patch is just doing: > > > > #include <sha1.h> > > > > At best this seems like a trivial bug and at worst us encoding some > > Suse-specific packaging convention in git, since other distros would > > presumably want to package this in /usr/include/sha1dc/sha1.h as > > upstream suggests. I.e. using the ambiguous sha1.h name is not > > something upstream's doing by default, it's something you're doing in > > your package. > > I do not think I saw any updates to this thread. Should I consider > the topic ti/external-sha1dc now abandoned? Sorry for the silence, as I've been too busy for other tasks (there were too many security bugs in the last weeks in many packages...) > As we have finished Git 2.14 cycle, in preparation for the next one, > the 'next' branch will be rewound and rebuilt early next week. I do > not mind tentatively ejecting some topics that needs fix-ups out of > 'next' to give them a clean restart. If there will be a reroll that > addresses the concerns raised during the discussion, please let me > know. Feel free to drop my branch, then. I'm going to resubmit the fix in anyway, hopefully in the next week. One thing I'm not entirely sure is about including the sha1.h as #include <sha1dc/sha1.h> Although the header is installed to sha1dc/sha1.h as default in the upstream package, the intention of this sha1.h is a sort of replacement of md1 (and possibly other) sha1.h. It's a drop-in. So in one side, including <sha1.h> with some include path is the intended behavior, while <sha1dc/sha1.h> would work (likely in a more safer manner) in practice. I'm inclined to go for <sha1dc/sha1.h> and fix SUSE sha1dc package before that, but I'd like to hear from others, too. thanks, Takashi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-07-28 15:58 ` Ævar Arnfjörð Bjarmason 2017-07-28 16:04 ` Ævar Arnfjörð Bjarmason @ 2017-08-01 5:46 ` Takashi Iwai 2017-08-01 15:56 ` Junio C Hamano 1 sibling, 1 reply; 13+ messages in thread From: Takashi Iwai @ 2017-08-01 5:46 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List, Andreas Stieger On Fri, 28 Jul 2017 17:58:14 +0200, Ævar Arnfjörð Bjarmason wrote: > > On Tue, Jul 25, 2017 at 7:57 AM, Takashi Iwai <tiwai@suse.de> wrote: > > Some distros provide SHA1 collision detect code as a shared library. > > It's the very same code as we have in git tree, and git can link with > > it as well; at least, it may make maintenance easier, according to our > > security guys. > > > > This patch allows user to build git linking with the external sha1dc > > library instead of the built-in sha1dc code. User needs to define > > DC_SHA1_EXTERNAL explicitly. As default, the built-in sha1dc code is > > used like before. > > This whole thing sounds sensible. I reviewed this (but like Junio > haven't tested it with a lib) and I think it would be worth noting the > following in the commit message / Makefile documentation: Hi, sorry for the late reply, and thanks for the review. > * The "sha1detectcoll" *.so name for the "sha1collisiondetection" > library is not something you or suse presumably) made up, it's a name > the sha1collisiondetection.git itself creates for its library. I think > the Makefile docs you've added here are a bit confusing, you talk > about the "external sha1collisiondetection library" but then link > against sha1detectcoll". It's worth calling out this difference in the > docs IMO. I.e. not talk about the sha1detectcoll.so library form of > sha1collisiondetection, not the sha1collisiondetection project name as > a library. Heh, I was confused and annoyed by this inconsistency, too :) IIRC, I used "sha1collisiondetection" since the text for DC_SHA1_SUBMODULE refers to this term already. I'll keep using the more readable term (e.g. SHA1 collision-detection or sha1dc as abbreviated form) instead of the project name. > * It might be worth noting that this is *not* linking against the same > code we ship ourselves due to the difference in defining > SHA1DC_INIT_SAFE_HASH_DEFAULT for the git project's needs in the one > we build, hence your need to have a git_SHA1DCInit() wrapper whereas > we call SHA1DCInit() directly. It might be interesting to note that > the library version will always be *slightly* slower (although the > difference will be trivial). Well, it's just a matter of definition of "code". If you think of the source code, it is the same code. The difference is merely the build option and how it's compiled. The performance difference is also not worth to note. If the call pattern differs due to shlib, it does change no matter whether it's with the same option or not. Using shlib always implies that, you must know it. In anyway, I'm going to rephrase "code" with "source code" to avoid confusion. > * Nothing in your commit message or docs explains why DC_SHA1_LINK is > needed. We don't have these sorts of variables for other external > libraries we link to, why the difference? IMO, it's other way round. If we didn't provide any such option for using external library, we were too lazy. Actually, I was lazy and didn't provide DC_SHA1_CFLAGS, and you've proven this to be bad -- the library header might be installed in a different location than the standard path. The DC_SHA1_CFLAGS can be set as default to -Isha1dc so that it covers that path. I'll add this to the revised patch. > Some other things I observed: > > * We now have much of the same header code copy/pasted between > sha1dc_git.h and sha1dc_git_ext.h, did you consider just always > including the former but making what it's doing conditional on > DC_SHA1_EXTERNAL? I don't know if it would be worth it from a cursory > glance, but again your commit message doesn't list that among options > considered & discarded. I don't mind either way, there is no perfect solution in this case. As you know, many people think the ifdef ugly no matter how. I leave the decision to maintainer. Just let me know which option is preferred. > * I think it makes sense to spew out a "not both!" error in the > Makefile if you set DC_SHA1_EXTERNAL=Y and DC_SHA1_SUBMODULE=Y. See my > 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) for an > example of how to do this. Yeah, that's a good point. Will add the check. > * The whole business of "#include <sha1.h>" looks very fragile, are > there really no other packages in e.g. suse that ship a sha1.h? Debian > has libmd-dev that ships /usr/include/sha1.h that conflicts with this: > https://packages.debian.org/search?searchon=contents&keywords=sha1.h&mode=exactfilename&suite=unstable&arch=any > > Shipping a sha1.h as opposed to a sha1collisiondetection.h or > sha1detectcoll.h or whatever seems like a *really* bad decision by > upstream that should be the subject of at least seeing if they'll take > a pull request to fix it before you package it or before we include > something that'll probably need to be fixed / worked around anyway in > Git. Yeah, a unique header name would be better indeed. thanks, Takashi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-08-01 5:46 ` Takashi Iwai @ 2017-08-01 15:56 ` Junio C Hamano 2017-08-01 16:12 ` Takashi Iwai 0 siblings, 1 reply; 13+ messages in thread From: Junio C Hamano @ 2017-08-01 15:56 UTC (permalink / raw) To: Takashi Iwai Cc: Ævar Arnfjörð Bjarmason, Git Mailing List, Andreas Stieger Takashi Iwai <tiwai@suse.de> writes: > On Fri, 28 Jul 2017 17:58:14 +0200, > Ævar Arnfjörð Bjarmason wrote: >> ... >> * We now have much of the same header code copy/pasted between >> sha1dc_git.h and sha1dc_git_ext.h, did you consider just always >> including the former but making what it's doing conditional on >> DC_SHA1_EXTERNAL? I don't know if it would be worth it from a cursory >> glance, but again your commit message doesn't list that among options >> considered & discarded. > > I don't mind either way, there is no perfect solution in this case. > As you know, many people think the ifdef ugly no matter how. > > I leave the decision to maintainer. Just let me know which option is > preferred. Yeah, I also found it somewhat confusing to have these two headers that look quite similar to each other at the top-level of the tree. What's the "conditional" part between the two headers? Is it just whether the header for underlying library is included? I wonder if it's just the matter of adjusting "hash.h" to read like this ... #if defined(DC_SHA1_EXTERNAL) -#include "sha1dc_git_ext.h" +#include <sha1dc/sha1.h> +#include "sha1dc_git.h" #elif defined(DC_SHA1_SUBMODULE) ... or are there heavier tweaks needed that won't be solved by continuing along the same line? As _ext.h variant is included only at this place, if we can do with minimum tweaks around here without introducing it, it may be ideal, I would think. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-08-01 15:56 ` Junio C Hamano @ 2017-08-01 16:12 ` Takashi Iwai 2017-08-01 19:55 ` Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 13+ messages in thread From: Takashi Iwai @ 2017-08-01 16:12 UTC (permalink / raw) To: Junio C Hamano Cc: Ævar Arnfjörð Bjarmason, Git Mailing List, Andreas Stieger On Tue, 01 Aug 2017 17:56:00 +0200, Junio C Hamano wrote: > > Takashi Iwai <tiwai@suse.de> writes: > > > On Fri, 28 Jul 2017 17:58:14 +0200, > > Ævar Arnfjörð Bjarmason wrote: > >> ... > >> * We now have much of the same header code copy/pasted between > >> sha1dc_git.h and sha1dc_git_ext.h, did you consider just always > >> including the former but making what it's doing conditional on > >> DC_SHA1_EXTERNAL? I don't know if it would be worth it from a cursory > >> glance, but again your commit message doesn't list that among options > >> considered & discarded. > > > > I don't mind either way, there is no perfect solution in this case. > > As you know, many people think the ifdef ugly no matter how. > > > > I leave the decision to maintainer. Just let me know which option is > > preferred. > > Yeah, I also found it somewhat confusing to have these two headers > that look quite similar to each other at the top-level of the tree. > > What's the "conditional" part between the two headers? Is it just > whether the header for underlying library is included? I wonder if > it's just the matter of adjusting "hash.h" to read like this > > ... > #if defined(DC_SHA1_EXTERNAL) > -#include "sha1dc_git_ext.h" > +#include <sha1dc/sha1.h> > +#include "sha1dc_git.h" > #elif defined(DC_SHA1_SUBMODULE) > ... > > or are there heavier tweaks needed that won't be solved by continuing > along the same line? As _ext.h variant is included only at this place, > if we can do with minimum tweaks around here without introducing it, > it may be ideal, I would think. Well, a tricky part is that currently sha1dc_git.h is included from sha1dc/sha1.h implicitly by SHA1DC_CUSTOM_TRAILING_INCLUDE_SHA1_H definition. IMO, we should stop this, and use the standard inclusion instead, i.e. in hash.h, #if defined(DC_SHA1_EXTERNAL) #include <sha1dc/sha1.h> #elif defined(DC_SHA1_SUBMODULE) #include "sha1collisiondetection/lib/sha1.h" #else #include "sha1dc/sha1.h" #endif #include "sha1dc_git.h" In sha1dc_git.h, we'd need another ifdef for DC_SHA1_EXTERNAL to define the own git_SHA1DCInit(), but it's trivial. Takashi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-08-01 16:12 ` Takashi Iwai @ 2017-08-01 19:55 ` Ævar Arnfjörð Bjarmason 2017-08-01 20:50 ` Takashi Iwai 0 siblings, 1 reply; 13+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-08-01 19:55 UTC (permalink / raw) To: Takashi Iwai; +Cc: Junio C Hamano, Git Mailing List, Andreas Stieger On Tue, Aug 01 2017, Takashi Iwai jotted: > On Tue, 01 Aug 2017 17:56:00 +0200, > Junio C Hamano wrote: >> >> Takashi Iwai <tiwai@suse.de> writes: >> >> > On Fri, 28 Jul 2017 17:58:14 +0200, >> > Ævar Arnfjörð Bjarmason wrote: >> >> ... >> >> * We now have much of the same header code copy/pasted between >> >> sha1dc_git.h and sha1dc_git_ext.h, did you consider just always >> >> including the former but making what it's doing conditional on >> >> DC_SHA1_EXTERNAL? I don't know if it would be worth it from a cursory >> >> glance, but again your commit message doesn't list that among options >> >> considered & discarded. >> > >> > I don't mind either way, there is no perfect solution in this case. >> > As you know, many people think the ifdef ugly no matter how. >> > >> > I leave the decision to maintainer. Just let me know which option is >> > preferred. >> >> Yeah, I also found it somewhat confusing to have these two headers >> that look quite similar to each other at the top-level of the tree. >> >> What's the "conditional" part between the two headers? Is it just >> whether the header for underlying library is included? I wonder if >> it's just the matter of adjusting "hash.h" to read like this >> >> ... >> #if defined(DC_SHA1_EXTERNAL) >> -#include "sha1dc_git_ext.h" >> +#include <sha1dc/sha1.h> >> +#include "sha1dc_git.h" >> #elif defined(DC_SHA1_SUBMODULE) >> ... >> >> or are there heavier tweaks needed that won't be solved by continuing >> along the same line? As _ext.h variant is included only at this place, >> if we can do with minimum tweaks around here without introducing it, >> it may be ideal, I would think. > > Well, a tricky part is that currently sha1dc_git.h is included from > sha1dc/sha1.h implicitly by SHA1DC_CUSTOM_TRAILING_INCLUDE_SHA1_H > definition. IMO, we should stop this, and use the standard inclusion > instead, i.e. in hash.h, It's just like this because when I hacked up that facility I was making the bare minimum change needed to not make local modifications to the upstream code. If there's better ways to do this in the presence of DC_SHA1_EXTERNAL & without that would be most welcome. Thanks. > #if defined(DC_SHA1_EXTERNAL) > #include <sha1dc/sha1.h> > #elif defined(DC_SHA1_SUBMODULE) > #include "sha1collisiondetection/lib/sha1.h" > #else > #include "sha1dc/sha1.h" > #endif > #include "sha1dc_git.h" > > In sha1dc_git.h, we'd need another ifdef for DC_SHA1_EXTERNAL to > define the own git_SHA1DCInit(), but it's trivial. > > > Takashi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] hash: Allow building with the external sha1dc library 2017-08-01 19:55 ` Ævar Arnfjörð Bjarmason @ 2017-08-01 20:50 ` Takashi Iwai 0 siblings, 0 replies; 13+ messages in thread From: Takashi Iwai @ 2017-08-01 20:50 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Junio C Hamano, Git Mailing List, Andreas Stieger On Tue, 01 Aug 2017 21:55:45 +0200, Ævar Arnfjörð Bjarmason wrote: > > > On Tue, Aug 01 2017, Takashi Iwai jotted: > > > On Tue, 01 Aug 2017 17:56:00 +0200, > > Junio C Hamano wrote: > >> > >> Takashi Iwai <tiwai@suse.de> writes: > >> > >> > On Fri, 28 Jul 2017 17:58:14 +0200, > >> > Ævar Arnfjörð Bjarmason wrote: > >> >> ... > >> >> * We now have much of the same header code copy/pasted between > >> >> sha1dc_git.h and sha1dc_git_ext.h, did you consider just always > >> >> including the former but making what it's doing conditional on > >> >> DC_SHA1_EXTERNAL? I don't know if it would be worth it from a cursory > >> >> glance, but again your commit message doesn't list that among options > >> >> considered & discarded. > >> > > >> > I don't mind either way, there is no perfect solution in this case. > >> > As you know, many people think the ifdef ugly no matter how. > >> > > >> > I leave the decision to maintainer. Just let me know which option is > >> > preferred. > >> > >> Yeah, I also found it somewhat confusing to have these two headers > >> that look quite similar to each other at the top-level of the tree. > >> > >> What's the "conditional" part between the two headers? Is it just > >> whether the header for underlying library is included? I wonder if > >> it's just the matter of adjusting "hash.h" to read like this > >> > >> ... > >> #if defined(DC_SHA1_EXTERNAL) > >> -#include "sha1dc_git_ext.h" > >> +#include <sha1dc/sha1.h> > >> +#include "sha1dc_git.h" > >> #elif defined(DC_SHA1_SUBMODULE) > >> ... > >> > >> or are there heavier tweaks needed that won't be solved by continuing > >> along the same line? As _ext.h variant is included only at this place, > >> if we can do with minimum tweaks around here without introducing it, > >> it may be ideal, I would think. > > > > Well, a tricky part is that currently sha1dc_git.h is included from > > sha1dc/sha1.h implicitly by SHA1DC_CUSTOM_TRAILING_INCLUDE_SHA1_H > > definition. IMO, we should stop this, and use the standard inclusion > > instead, i.e. in hash.h, > > It's just like this because when I hacked up that facility I was making > the bare minimum change needed to not make local modifications to the > upstream code. If there's better ways to do this in the presence of > DC_SHA1_EXTERNAL & without that would be most welcome. Thanks. Can't it be like the code below? sha1.h is included only via hash.h, and sha1dc_git.h doesn't matter for the compile of sha1dc/*.c. Or am I missing something...? > > #if defined(DC_SHA1_EXTERNAL) > > #include <sha1dc/sha1.h> > > #elif defined(DC_SHA1_SUBMODULE) > > #include "sha1collisiondetection/lib/sha1.h" > > #else > > #include "sha1dc/sha1.h" > > #endif > > #include "sha1dc_git.h" thanks, Takashi > > > > In sha1dc_git.h, we'd need another ifdef for DC_SHA1_EXTERNAL to > > define the own git_SHA1DCInit(), but it's trivial. > > > > > > Takashi > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-08-12 6:50 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-25 5:57 [PATCH] hash: Allow building with the external sha1dc library Takashi Iwai 2017-07-25 19:06 ` Junio C Hamano 2017-07-28 15:58 ` Ævar Arnfjörð Bjarmason 2017-07-28 16:04 ` Ævar Arnfjörð Bjarmason 2017-07-31 22:28 ` Junio C Hamano 2017-08-01 5:52 ` Takashi Iwai 2017-08-12 0:42 ` Junio C Hamano 2017-08-12 6:50 ` Takashi Iwai 2017-08-01 5:46 ` Takashi Iwai 2017-08-01 15:56 ` Junio C Hamano 2017-08-01 16:12 ` Takashi Iwai 2017-08-01 19:55 ` Ævar Arnfjörð Bjarmason 2017-08-01 20:50 ` Takashi Iwai
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).