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.

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)

Which are? I'm not joking, "GitHub broken" and "Google has issues" are not arguments against a better encryption default.

The submodule argument is transitional at best.

As for the pro side (note that this is my opinion, I'm not deeply involved in the discussion - and with not deeply I mean "not at all"):

The case the author aggressively ridiculed ("I don't use GPG to trust, I trust the GitHub authentication!) is one that anyone would have if they'd want to stay safe from centralized systems.

Another is upstream availability: once an algorithm is identified as broken (no matter how small) usage drops rapidly - there's a reason why no one uses md5 anymore although it "would be fine" for purely collision mitigation.

And then there the simple fact that the integrity hash is a security feature, not purely anti collision (as the author also describes). Just because they (nor I!) can't see an attack vector at the moment doesn't make this less of an issue.

In short: it's the other way around: you'd need way stronger arguments than "there will be a transition pain" to knowingly compromise your security.

Apparently, the whole argumentation is kind of daft and making wrong assumptions: https://programming.dev/post/57383912/26317185

I don't think they'll drop sha256. The breaking change is that it's now the default instead of sha1.

It's too late for this to have any effect. It's more "brace for the shitty unnecessary storm".

If you thought "main" was stupid...

Don't be insane, they only skipped 254 versions

Filler episodes.

Thanks for sharing.

Why didn't I know lobsters before? This look 1000 times better than HN... oh you can't join. Makes sense it isn't that known.

I think he's maybe overblowing the impact of this change.

Maybe... But I don't look forward to working with the dozens of IT folks at my company who all installed git once and have never upgraded. This will be multiple meetings, show up on slide decks, break builds...

It's going to be a right pain for nothing.

Wait, they don't affect security? Wouldn't a hash collision mean pulling that hash from GitHub would pull wrong code? Or maybe delete code? I'd assume the hash is used as a lookup key in a database somewhere.

You also pin dependencies to specific hashes for security reasons.

I would have thought they’d prefix the hash with “sha256-“ or something, or even just 256 prefix the hash.

Collision concerns make sense. If you manage to get two different files with the same hash, that will cause issues for your repo - the concerns over a collision justify the move to SHA-256 though.

You're probably more qualified than most HNers, just less confident, less inclined to indulge in performative expertise and pseudo-intellectual posturing, and more resistant to joining the circle-jerks with those who do indulge.

If you know of write-ups by others on this, you are welcome to share. It was a pretty long post, so I mentioned who authored it. If it was on, say, LWN, I wouldn't have prefixed anything to the topic. It looks like it also helps people to avoid rich-man blogs (if they want to)!

But signing keys can be stolen, have to be updated, revoked etc. A secure hash is an elegant way to say "this repo contains what I want"

he gives a pretty reasonable solution at the end? basically his point is the implementation is problematic and causes churn for everyone who uses git and if the concern is really about security then they would allow swapping out the verification hash instead of hard coding it again and waiting for 256 to be broken.

Wayland actually increases the barrier to entry by improving the security model.

Git commit hashes were never meant for security or trust, and trying to crowbar them into that role is shortsighted, as Linus argues.

Personally, I'm in favor of the migration and would already be using it (except Nix only supports sha1 atm). But, the security argument isn't a good one.

I'm in favor of a better hashing algorithm because the hash will be a better hash, not because I think it will improve the cryptographic security and trust of my repos. But honestly, that's just a nerd mental thing. I could take it or leave it. SHA1 is sufficient for the role.

I don't think your Wayland comparison is great. There are already solutions to app isolation that make X a weak link, e.g. Android or Qubes. Whereas there's basically no future where SHA1 in Git is the weakest link.

Also security was only one reason for Wayland.

Addressed in the article.

I read that whole article, and aside from an unsourced statement that GitHub et al will need "new and distinct servers" exactly zero of that seemed to support the thesis that a SHA-256 default was going to be "expensive".

Submodules are not the preferred way to incorporate third-party code for any environment I know. And while web-exposed URLs for management tools like Jira or AzureDevOps will need to adapt before the new default can be used, doing so even with a wholesale re-hashing of every commit isn't technically difficult.

What would be terrible and dangerous would be if git 3.0 entirely dropped SHA-1 support. But just as you're free to keep on using "master" instead of "main", i expect that extant projects will still be supported until a version after every major project has converted to SHA-256 or what have you.

There's apparently work going on to have on the fly translations between SHA-1 and SHA-256 as necessary

https://git-scm.com/docs/hash-function-transition