14

Does the current version of git (2.30.0) already use SHA256 to calculate commit hashes by default?

If not, how can SHA-256 be enabled for a new git repository and how can be checked whether a certain git repository uses SHA-256 or SHA-1 for its commit hashes?

isherwood
  • 58,414
  • 16
  • 114
  • 157
matthias_buehlmann
  • 4,641
  • 6
  • 34
  • 76
  • 2
    @mkrieger1 unfortunately no. I have seen multiple documents and articles regarding this move from 2017. but it's 2021 now, my question is whether this is now enabled by default and if not, how to use it? – matthias_buehlmann Jan 24 '21 at 12:30
  • 1
    @ArkadiuszDrabczyk because SHA-1 isn't really that secure anymore - so if you wanna use the commit hash to prove integrity for example, SHA-1 wouldn't be considered secure anymore in many contexts. – matthias_buehlmann Jan 24 '21 at 12:59
  • 3
    You might note that all constructed hashcode collisions in ever-considered-secure hashes are in .pdf's (and perhaps similar formats, but I think they're all .pdf's). That's because humans don't look at .pdf's directly, they look at a rendering, and you can hide a colossal amount of bullshit in a .pdf. The sort that it takes to steer a good hash code into producing a collision. Anybody trying to produce two snapshots that both looks sensible to a human eye has a much, *much* more daunting task in front of them. – jthill Jan 24 '21 at 13:11
  • 1
    Agreed - but there is sometimes legislation that puts requirements on cryptographic securit. In particular, I would like to proof that commits existed at a cetain time by timestamping them using a (govenmentally trusted) TSA and the corresponding legislation that defines what is trusted specifies that hashes must be at least SHA-256 – matthias_buehlmann Jan 24 '21 at 13:17
  • 2
    That's completely false. Signing commits or tags relies on SHA-1 for security with the Merkle tree. – bk2204 Jan 24 '21 at 21:23
  • 1
    @Chris "signing a commit" means signing its hash. If you sing a SHA-1 hash to prove something and certain rules require for hash based proves at least SHA-256, then that won't work – matthias_buehlmann Jan 25 '21 at 12:48

3 Answers3

18

Whether to use SHA-1 or SHA-256 is a per-repository setting in recent versions of Git. The plan is eventually to make it possible to store data in a repository in SHA-256 and access the objects with either the SHA-1 name or the SHA-256 name. SHA-1 remains the default.

Do note that the SHA-256 mode is experimental and could theoretically change but there are no plans to do so. The Git developers are making every effort to not break compatibility with existing SHA-256 repositories.

To create a new repository with SHA-256, use the --object-format option to git init. If you want to know which algorithm a local repository uses, run git rev-parse --show-object-format, which will output either sha1 or sha256. To see the hash of a remote repository, you can use git ls-remote and verify the length of the hashes printed.

Do note that no major forges support SHA-256 and therefore such repositories cannot be uploaded to them.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • 2
    Thank you! this is very relevant information. Do you know whether there is any ETA on when to make this feature non-experimental on git and when it might be supported by github? This seems to be a feature that's cooking already for quite a while – matthias_buehlmann Jan 25 '21 at 12:55
  • 4
    I'm the primary person working on it on the Git side and it happens in my free time, so it's hard to say. Interoperability is coming, but the work is slow. As for GitHub, I can't speak to the product roadmap. If you want to see it (especially if you're a corporate user), let GitHub Support know, since GitHub tracks customer feedback and feature requests. – bk2204 Jan 25 '21 at 23:28
9

According to the man page for git-init for version 2.30.0, the sha-256 support is still considered experimental:

--object-format=<format

    Specify the given object format (hash algorithm) for the
    repository. The valid values are sha1 and (if enabled) sha256.
    sha1 is the default.

    THIS OPTION IS EXPERIMENTAL! SHA-256 support is experimental and
    still in an early stage. A SHA-256 repository will in general not
    be able to share work with "regular" SHA-1 repositories. It should
    be assumed that, e.g., Git internal file formats in relation to
    SHA-256 repositories may change in backwards-incompatible ways.
    Only use --object-format=sha256 for testing purposes.
larsks
  • 277,717
  • 41
  • 399
  • 399
  • worked for me `mkdir sha256 && cd sha256` `git init --object-format=sha256` `dd if=/dev/zero bs=$((1024*1024)) count=$((5*1024)) | git hash-object --stdin --literally` result `dc18ca621300c8d3cfa505a275641ebab00de189859e022a975056882d313e64`, on WSL Ubuntu `git version 2.33.1` – Philip Oakley Nov 04 '21 at 16:40
2

According to the man page for git-init for version 2.30.0, the sha-256 support is still considered experimental:

Actually, Git 2.42 (Q3 2023) tones down the warning on SHA-256 repositories being an experimental curiosity.
There is no support (yet) for them to interoperate with traditional SHA-1 repositories, but at this point, there is no plan to make breaking changes to SHA-256 repositories and there is no longer need for such a strongly phrased warning.

See commit 8e42eb0 (31 Jul 2023) by Adam Majer (AdamMajer).
(Merged by Junio C Hamano -- gitster -- in commit e48d9c7, 07 Aug 2023)

doc: sha256 is no longer experimental

Signed-off-by: Adam Majer

Remove scary wording that basically stops people using sha256 repositories not because of interoperability issues with sha1 repositories, but from fear that their work will suddenly become incompatible in some future version of git.

We should be clear that currently sha256 repositories will not work with sha1 repositories but stop the scary words.

git now includes in its man page:

is always used. The default is "sha1". See --object-format in git init.

object-format-disclaimer now includes in its man page:

Note: At present, there is no interoperability between SHA-256 repositories and SHA-1 repositories.

Historically, we warned that SHA-256 repositories may later need backward incompatible changes when we introduce such interoperability features. Today, we only expect compatible changes. Furthermore, if such changes prove to be necessary, it can be expected that SHA-256 repositories created with today's Git will be usable by future versions of Git without data loss.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250