89
Git 3.0's upcoming SHA-256 default will be a costly mistake (blog.gitbutler.com)
submitted 5 days ago by to c/programming@programming.dev
25 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 55 points 4 days ago (14 children)

I tried to implement my own git from scratch. And when I got to choose a hashing algorithm, I reached the exact same conclusion as the author pretty fast.

The hashing algorithm doesn't really matter as long as it's good enough to prevent accidental collisions. And if there is a collision, it is extremely easy to check.

If you are about to create a new object and an object with that hash already exists, you compare the 2 objects. If they are the same, nothing happened. If they are different, you just found a collision. Throw some obscure error that will only be witnessed once in the lifetime of the universe and be done with it. Tell the user to change a single bit of the input and be done with it.

The purpose of object hashes in git was never to provide security. Security is achieved through other means.

  • permalink
  • fedilink
  • source
  • hideshow 14 child comments
    •
  • [–] 6 points 3 days ago* (last edited 3 days ago) (6 children)

    Security is achieved through other means.

    Let's explicit this: you can, and should, sign your commits if you want security (no commit tampering). You need to:

    • generated a gpg key: gpg --full-generate-key
    • set git to look for the public key to use: git config --global user.signingkey [public key ID]
    • set git to sign your commits: git config --global commit.gpgsign true

    Note that I used --global here but you can do without to sign on a per-project basis.

    Also gpg UX is terrible, to find the [public key ID] use the command gpg --list-keys, it should looks like:

    pub   ed25519 2026-01-01 [SC] <- type algorithm date and capability (this key is only to Sign and Certify)
      662E3CDD6FE329002D0CA5BB40339DD82B12EF16 <- Public key ID
uid           [ultimate] my full name (Master Key) <my_email@domain.com> <- owner information (should be your name and email address)
sub   rsa4096 2026-01-01 [E] <- sub key used to encrypt
sub   ed25519 2026-01-01 [S] [expires: 2027-01-01] <- subkey used to sign

    Last, if you want to save/backup you keys the default location of gpg files is ~/gnupg or you can export keys with gpg --export [key ID] > path/to/file.key for the public part and gpg --export-secret-keys [private key ID] for the private part. Both export can have a -a or --armor argument to output as base64 text instead of raw binary. [private key ID] can be found with gpg --list-secret-keys.

    EDIT: after writing this I checked https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work and TIL you can sign tags too.

    EDIT 2: you can also use your ssh key to sign -> git config --global gpg.format ssh (I am less inclined to do this as you won't have subkeys and expiration date but this would be simplier indeed)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 4 points 3 days ago (4 children)

    Worth to keep in mind though that the gpg signature basically only signs the (git) hashes of the contained objects, so the choice of hash function is indeed important for security.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 3 days ago* (last edited 3 days ago) (3 children)

    Indeed it is still relevant. I am wondering what does it sign for tags.

    EDIT: Are you sure about that? signing the hash felt logical but digging about it this seems a false assumption. git is signing the whole commit object.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 3 days ago (2 children)

    Yes, but the "commit object" is just a bunch of metadata that refers to the tree by its hash:

    % git cat-file commit 6de20f6092
tree 5cb21f9acf8c31ce1a8f6bb0bbc3b9e4e8607ce8
parent c679abf7d2c0f3f4ee623e0882a50964e9b100cc
author Junio C Hamano <gitster@pobox.com> 1791306800 -0700
committer Junio C Hamano <gitster@pobox.com> 1791306812 -0700

The 4th batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>

    And the tree in turn refers to the files (or subfolders) by their hashes:

    % git cat-file -p 5cb21f9acf8c31ce1a8f6bb0bbc3b9e4e8607ce8 | head
100644 blob fd4fb56b6d56789369d4824ad10999369127f5c7	.b4-config
100644 blob 8168d8a10b3a9e14f6c019e8ffbe5a71dc307d8b	.b4-cover-template
100644 blob fef04a38402fee6465a6a4225374d493b47421c0	.cirrus.yml
100644 blob 86b4fe33e5cd98e2a347944559c345419824c245	.clang-format
100644 blob 82e121a41754b536611c9ce9b2b4aba349e7ed9d	.editorconfig
100644 blob 26490ad60a74d0968eaf2f77abffcb21d78b18e3	.gitattributes
040000 tree 5f898fc5ec3429058fd21072db170fff9e49eab4	.github
100644 blob 0209bd16f209c232748734d911099b37be80fc12	.gitignore
100644 blob 3f2483550038f6aabb2f8b858b4ee7b29a66072a	.gitlab-ci.yml
100644 blob cbeebdab7a5e2c6afec338c3534930f569c90f63	.gitmodules

    If you can produce a hash collision, you can therefore have two repositories with the same signed commit but different file content.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 days ago (1 child)

    Yes you are right, damned! Why git isn't signing the diff (patch)? This is so wrong on so many level, signing already hash the content, we can sign multiple GiB without any issue.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 2 days ago

    Hm, I wouldn't call it wrong on many levels, I think it's quite elegant. It's a form of a Merkle Tree, and knowing the hash of a commit does not just allow you to verify its content, but also the whole history up to that point (as the commit contains the hash of its parent, which in turn contains hashes of its content and parents). I guess that's not too unimportant if you consider scenarios where you pull code from distributed repositories (like forks), as you can ensure that the parts of the history you know are actually what they claim to be. And if you accept hash-then-sign as being secure, this is just as secure for signed commits (assuming the hash function is secure).

    I think the only unfortunate part here is that git ended up using SHA-1 as a hash function, which 20 years ago might or might not have been a reasonable choice -- I don't know how "broken" it was regarded back then, or how widespread SHA-256 use was.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 7 points 3 days ago (6 children)

    Even if it's not the purpose it can fulfill it. Hashes are used for all kinds of things like traceability or for pinning versions. They are used in a context where people depend on that a hash always has the same code behind it and SHA1 can not guarantee that anymore. A better hashing algo is needed to keep the way how people use git secure.

    It's not enough to say "you shouldn't use it that way". We have to accept the reality of how git is used and adapt.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 6 points 3 days ago (5 children)

    If someone has access to write to a repo you are downloading code from, and you don't trust that someone, you shouldn't be running the code in that repo.

    The only "security" vulnerability is: I have audited and verified that the code in commit 05682ab36ca. And I will use only that version.

    What you do then is: download that commit and store it in a local repo, and package it so you can distribute it to your clients.

    Auditing external software is tremendous effort, even if it is open source. Using your local repo instead of downloading that commit from GitHub every time is very little extra effort in comparison.

    And if you really need it. You can always hash with sha256 yourself and verify that the commit with that sha1 still produces the same sh256. So you can keep downloading it each time, just need to store the sha256.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 3 days ago (4 children)

    You are exactly doing what I described. You are saying "your using it wrong" instead of acknowledging that's how people use it and and then improving that. You might not need this feature because you are "using it correctly" but that doesn't matter. For the lived reality of many people sha256 is the correct move.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 3 days ago (3 children)

    I've never heard of anyone relying on git's sha1 hashed for security

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 3 days ago (2 children)

    I have. In some languages you can use git repos as dependencies. It's good practice to use hashes instead if tags because tags are not immutable. SHA1 hashes are better than tags but better hases would be even better.

    Also traceability. You can build a chain from your commit over ci to the artifact if you do it right. If you can change the files to a hash you can destroy that trust chain. Sha256 makes that impossible.

    People use the hashes in ways you might not. It wasn't meant as a trust anchor but it became one. And that is now being addressed. I also think that the git maintainers have put a lot of thought into backward compatability and making the change as painless as possible.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 days ago (1 child)

    Good practice != Something that ensures security. As I said, it's an even better practice to just host your own fork if what you want is security. The reason to use git hashes is mostly so you don't have to trust the author following semver in there version number. It's a matter of ensuring that your code will always compile, not a security feature.

    Have you read the article? Your arguments derive from an assumption of "sha1 is mutable, sha256 is immutable". First of all, every hashing algorithm is going to have collisions, that's an unavoidable "feature" of hashes. And sha1 is in no way "mutable", it takes a great amount of effort (and money) to generate a collision. Furthermore, those collisions are not arbitrary. You have to calculate them beforehand. As the article says: what is more likely? Paying 40k€ in compute time to generate a single collision? Or just paying an open source maintainer 40k€ to let you do 1 new commit that most people are going to download anyway?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 3 days ago

    Yes I read the article. I don't agree with all the conclusions.

    Now is the best time to change to a new algo. SHA1 is not completely broken yet. It most probably will be at some point.

    Also AFAIK they will have compatibility tools for SHA1 repos in git. I don't see the big deal with the path they chose.

    We will probably nor agree on that one. I think the hashes are important and that they are mutable right new with effort and later without. It's okay that we don't agree though. The git maintainers have made their decision anyways.

  • permalink
  • fedilink
  • source
  • parent