All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Stephen Smith <ischis2@cox.net>, git <git@vger.kernel.org>,
	Jeff King <peff@peff.org>
Subject: Re: SHA-256 transition
Date: Wed, 22 Jun 2022 00:29:59 +0000	[thread overview]
Message-ID: <YrI9dvfoc5NYgVDq@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <220621.86sfnyuvt0.gmgdl@evledraar.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]

On 2022-06-21 at 10:25:01, Ævar Arnfjörð Bjarmason wrote:
> 
> But the reason I'd still say "no" on the technical/UX side is:
> 
>  * The inter-op between SHA-256 and SHA-1 repositories is still
>    nonexistent, except for a one-off import. I.e. we don't have any
>    graceful way to migrate an existing repository.

True, but that doesn't meant that new repositories couldn't use SHA-256.

>  * For new repositories I think you'll probably want to eventually push
>    it to one of the online git hosting providers, none of which (as far
>    as I'm aware) support SHA-256 repos.

This, in my view, is the only compelling reason not to use it for new
repositories.

>  * Even if not, any local git tooling that's not part of git.git is
>    likely to break, often for trivial reasons like expecting SHA-1 sized
>    hashes in the output, but if you start using it for your repositories
>    and use such tools you're very likely to be the first person to run
>    into bugs in those areas.

It's my hope to see libgit2 working on SHA-256 repositories in the
relatively near future.

> But more importantly (and note that these views are definitely *not*
> shared by some other project members, so take it with a grain of salt):
> There just isn't any compelling selling point to migrate to SHA-256 in
> the near or foreseeable future for a given individual user of git.

I wholly disagree.  SHA-1 is obsolete, and as soon as hosting providers
support SHA-256, all new repositories should be SHA-256.  There is no
other defensible reason to continue to use SHA-1 today.

> The reason we started the SHA-1 -> $newhash (it wasn't known that it
> would be SHA-256 at the time) was in response to https://shattered.io;
> Although it had been discussed before, e.g. the thread starting at [1]
> in 2012.
> 
> We've since migrated our default hash function from SHA-1 to SHA-1DC
> (except on vanilla OSX, see [2]). It's a variant SHA-1 that detects the
> SHAttered attack implemented by the same researchers. I'm not aware of a
> current viable SHA-1 collision against the variant of SHA-1 that we
> actually use these days.

That's true, but that still doesn't let you store the data.  There is
some data that you can't store in a SHA-1 repository, and SHA-1DC is
extremely slow.  Using SHA-256 can make things like indexing packs
substantially faster.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2022-06-22  0:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20 22:51 SHA-256 transition Stephen Smith
2022-06-20 23:13 ` rsbecker
2022-06-21 10:25 ` Ævar Arnfjörð Bjarmason
2022-06-21 13:18   ` rsbecker
2022-06-21 18:14     ` Ævar Arnfjörð Bjarmason
2022-06-22  0:29   ` brian m. carlson [this message]
2022-06-23  0:45     ` Stephen Smith
2022-06-23  1:44       ` brian m. carlson
2022-06-23 15:32         ` Junio C Hamano
2022-06-23 22:21     ` Ævar Arnfjörð Bjarmason
2022-06-24  0:29       ` Kyle Meyer
2022-06-24  1:03       ` Stephen Smith
2022-06-24  1:19         ` Ævar Arnfjörð Bjarmason
2022-06-24 14:42           ` Jonathan Corbet
2022-06-24 10:52     ` Jeff King
2022-06-24 15:49       ` Ævar Arnfjörð Bjarmason
2022-06-25  8:53       ` brian m. carlson
2022-06-26  0:09         ` Plan for SHA-256 repos to support SHA-1? Eric W. Biederman
2022-06-26  0:27           ` Junio C Hamano
2022-06-26 15:19             ` brian m. carlson
2022-07-01 18:00         ` SHA-256 transition Jeff King

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=YrI9dvfoc5NYgVDq@tapette.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ischis2@cox.net \
    --cc=peff@peff.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.