git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: SHA-256 transition

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jun 22, 2022, 00:29 UTC
Message-ID
<YrI9dvfoc5NYgVDq@tapette.crustytoothpaste.net>
In-Reply-To
<220621.86sfnyuvt0.gmgdl@evledraar.gmail.com>
On 2022-06-21 at 10:25:01, Ævar Arnfjörð Bjarmason wrote:
Show 6 quoted lines
> 
> 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.

Show 5 quoted lines
>  * 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.

Show 10 quoted lines
> 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
Previous: Ævar Arnfjörð BjarmasonNext: Stephen Smith
Message 6 of 21 in “SHA-256 transition”
  1. Stephen SmithJun 20, 2022
  2. rsbecker@nexbridge.comJun 20, 2022
  3. Ævar Arnfjörð BjarmasonJun 21, 2022
  4. rsbecker@nexbridge.comJun 21, 2022
  5. Ævar Arnfjörð BjarmasonJun 21, 2022
  6. brian m. carlsonJun 22, 2022
  7. Stephen SmithJun 23, 2022
  8. brian m. carlsonJun 23, 2022
  9. Junio C HamanoJun 23, 2022
  10. Ævar Arnfjörð BjarmasonJun 23, 2022
  11. Kyle MeyerJun 24, 2022
  12. Stephen SmithJun 24, 2022
  13. Ævar Arnfjörð BjarmasonJun 24, 2022
  14. Jonathan CorbetJun 24, 2022
  15. Jeff KingJun 24, 2022
  16. Ævar Arnfjörð BjarmasonJun 24, 2022
  17. brian m. carlsonJun 25, 2022
  18. Plan for SHA-256 repos to support SHA-1?Eric W. Biederman, Jun 26, 2022
  19. Junio C HamanoJun 26, 2022
  20. brian m. carlsonJun 26, 2022
  21. Jeff KingJul 1, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.