Thread

Git 3.0's upcoming SHA-256 default will be a costly mistake

570 points · 536 comments · chmaynard

purpleidea · 1790876403 · focus · HN ↗
This means, if you migrate your repo, every single commit message that contains text like: "please see commit <sha1>" will now be broken.
This will be a train wreck. I hope they don't release before adding compatibility modes to keep the existing sha1's around in the database.
1. oasisaimlessly · 1790876933 · focus · HN ↗
  Tools like git-filter-repo[1] support rewriting commit hashes in commit messages. git-filter-repo actually does it by default; see `--preserve-commit-hashes` in the manual[2].
  [1]: <a href="https://github.com/newren/git-filter-repo" rel="nofollow">https://github.com/newren/git-filter-repo
  [2]: <a href="https://htmlpreview.github.io/?https://github.com/newren/git-filter-repo/blob/docs/html/git-filter-repo.html" rel="nofollow">https://htmlpreview.github.io/?https://github.com/newren/git...
  1. donatj · 1790877983 · focus · HN ↗
    Sure, but that's not going to rewrite Slack messages, emails, GitHub links, docs
    purpleidea · 1790878692 · focus · HN ↗
    Came to say something exactly like this... The old sha1 handle needs to be still available in the same way an HTTP 301 redirect would work.
    functional_dev · 1790933939 · focus · HN ↗
    [dead]
    diegocg · 1790878864 · focus · HN ↗
    ... do not migrate old repos? I'm not sure why people would do that. Or, if they do, why would they replace the current repo name instead of creating a different one and keeping the old one closed to make the references work.
    I don't think this is going to be a problem at all.
    beart · 1790887024 · focus · HN ↗
    Hmm. If this is a security issue that matters, would you not be expected to migrate?
    Not talking about archived code, but active projects that pre-date git 3.0
    cylemons · 1790949216 · focus · HN ↗
    His point is keep an archived sha1 version of the repo and an active sha256 version.
    That way an old commit with a message having a sha1 can reference the archived version, and new commits reference the active version.
    krupan · 1790914513 · focus · HN ↗
    If we don't need to migrate repos to sha256 them why do we need to change git to use sha256?
    samus · 1790921708 · focus · HN ↗
    You keep the old repo for archival purposes and work with the new one.
    hinkley · 1790932043 · focus · HN ↗
    Some companies survive longer than five years. So old repos are also active ones.
    samspot · 1790963492 · focus · HN ↗
    I run into broken documentation links all the time at work. A few more isn't going to break us.
  2. okanat · 1790895003 · focus · HN ↗
    I need git-filter-repo to rewrite entire documentation and also resurrect and rehire earlier employees to repeat their GPG signatures.
2. windsurfer · 1790878087 · focus · HN ↗
  Since SHA-1 is already broken (just expensive in terms of GPU-time), then the text "please see commit <sha1>" is also already broken.
  1. Dylan16807 · 1790878278 · focus · HN ↗
    You can't attack an existing normal commit.
    But also collisions there aren't a big deal. People will cite short hashes when referring to things and that's not "broken".
    windsurfer · 1790890210 · focus · HN ↗
    If it's an existing commit and you're already converting the repo, you can just convert the commit messages as well.
  2. schacon · 1790879573 · focus · HN ↗
    That is essentially only a second preimage problem, which is basically impossible.
    [deleted] · 1790883948 · focus · HN ↗
    [deleted]
3. 112233 · 1790878309 · focus · HN ↗
  Once this starts being actual pain, we will each vibe the replacement index creator (git already supports replacement objects), for back-forth conversion, populated on pack and object indexing.
  For massive perf and mem use damage. But oh well. And then we will wait for official version
4. schacon · 1790879465 · focus · HN ↗
  There are plans to keep sha1s around in a database, but as far as I know, no way to transmit those, so they seem specific to individual forges. They can be recomputed, sure, but again, any signatures break and it's possible that in the case of an actual replacement, the recomputation is now wrong and not easily comparable. So what is the point?
  1. purpleidea · 1790885403 · focus · HN ↗
    This is not about forges, it is about the repo I have in a folder on my computer. The sha1 hashes shouldn't go away. Yes the forges also need to support this.
5. OneDeuxTriSeiGo · 1790910215 · focus · HN ↗
  Note that there exists multiple ways to continue to lookup SHA1s in a SHA256 repo.
  One example is to maintain git-replace refs for the rewritten SHAs but there also exist config flags to enable object format compatibility extensions that help translate the SHAs back and forth.
  <a href="https://git-scm.com/docs/git-replace" rel="nofollow">https://git-scm.com/docs/git-replace

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.