git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Jeff King <peff@peff.net>,
	Jeff Hostetler <jeffhost@microsoft.com>,
	Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1
Date: Wed, 27 Dec 2017 15:39:12 -0800	[thread overview]
Message-ID: <20171227233912.GB181628@aiede.mtv.corp.google.com> (raw)
In-Reply-To: <20171227230038.14386-2-avarab@gmail.com>

Hi,

Ævar Arnfjörð Bjarmason wrote:

> Stop supplying BLK_SHA1=YesPlease when NO_OPENSSL=UnfortunatelyYes is
> supplied. This has been done ever since [1], when switching to DC_SHA1
> by default in [2] this should have been changed as well.

I had trouble parsing this, I think for a few reasons:

 1. Too much 'this', so I end up not being able to keep track of what
    has been done ever since (1) and (2)

 2. The ',' should be a ';'

 3. Can the commit names go inline in the message instead of being
    footnotes?  That way, my eye doesn't have to chase so far to
    find what kind of dates you are talking about.

 4. Why should switching to DC_SHA1 by default have resulted in
    simply dropping the NO_OPENSSL => BLK_SHA1 behavior?  At first
    glance it would be more intuitive to change it to
    NO_OPENSSL => DC_SHA1 instead.

Putting those all together, I end up with

 Use the collision detecting SHA-1 implementation by default even
 when NO_OPENSSL is set.

 Setting NO_OPENSSL=UnfortunatelyYes has implied BLK_SHA1=1 ever since
 the former was introduced in dd53c7ab29 (Support for NO_OPENSSL,
 2005-07-29).  That implication should have been removed when the
 default SHA-1 implementation changed from OpenSSL to DC_SHA1 in
 e6b07da278 (Makefile: make DC_SHA1 the default, 2017-03-17).  Finish
 what that commit started by removing the BLK_SHA1 fallback setting so
 the default DC_SHA1 implementation can be used.

What happens if I set both OPENSSL_SHA1 and NO_OPENSSL?  Should this
block set

	OPENSSL_SHA1 =

so that the latter wins, or should we detect it as an error?

[...]
> --- a/Makefile
> +++ b/Makefile
> @@ -23,7 +23,6 @@ all::
>  # it at all).
>  #
>  # Define NO_OPENSSL environment variable if you do not have OpenSSL.
> -# This also implies BLK_SHA1.
>  #
>  # Define USE_LIBPCRE if you have and want to use libpcre. Various
>  # commands such as log and grep offer runtime options to use
> @@ -1260,7 +1259,6 @@ ifndef NO_OPENSSL
>  	endif
>  else
>  	BASIC_CFLAGS += -DNO_OPENSSL
> -	BLK_SHA1 = 1
>  	OPENSSL_LIBSSL =
>  endif
>  ifdef NO_OPENSSL
> diff --git a/configure.ac b/configure.ac
> index 2f55237e65..7f8415140f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -241,7 +241,6 @@ AC_MSG_NOTICE([CHECKS for site configuration])
>  # a bundled SHA1 routine optimized for PowerPC.
>  #
>  # Define NO_OPENSSL environment variable if you do not have OpenSSL.
> -# This also implies BLK_SHA1.

With or without some of those commit message tweaks
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks,
Jonathan

  reply	other threads:[~2017-12-27 23:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-27 23:00 [PATCH 0/2] When DC_SHA1 was made the default we missed a spot Ævar Arnfjörð Bjarmason
2017-12-27 23:00 ` [PATCH 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1 Ævar Arnfjörð Bjarmason
2017-12-27 23:39   ` Jonathan Nieder [this message]
2017-12-28 14:07     ` [PATCH v2 0/2] When DC_SHA1 was made the default we missed a spot Ævar Arnfjörð Bjarmason
2017-12-28 14:07     ` [PATCH v2 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1 Ævar Arnfjörð Bjarmason
2017-12-28 19:05       ` Jonathan Nieder
2017-12-28 14:07     ` [PATCH v2 2/2] Windows: stop supplying BLK_SHA1=YesPlease by default Ævar Arnfjörð Bjarmason
2017-12-28 19:04       ` Jonathan Nieder
2018-01-04 17:33       ` Johannes Schindelin
2018-01-04 18:30         ` Ævar Arnfjörð Bjarmason
2018-01-05 18:52           ` Junio C Hamano
2017-12-27 23:00 ` [PATCH " Ævar Arnfjörð Bjarmason
2017-12-27 23:42   ` Jonathan Nieder
2017-12-28 13:47     ` Ævar Arnfjörð Bjarmason
2018-01-04 17:35       ` Johannes Schindelin

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20171227233912.GB181628@aiede.mtv.corp.google.com \
    --to=jrnieder@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=jeffhost@microsoft.com \
    --cc=peff@peff.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.
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).