[shurcooL]

(When I saw the title, I was wondering if this does something beyond the basic rebase, like trying to brute force a commit such that all following commits are preserved (hash doesn't change), but that's essentially impossible.)

I'm tempted to make the observation that there's nothing here you can't already do with a git rebase -i and:

    GIT_COMMITTER_NAME=a GIT_COMMITTER_EMAIL=[e-mail] GIT_COMMITTER_DATE=2006-01-02T15:04:05Z git commit --author='a <[e-mail]>' --date 2006-01-02T15:04:05Z

But I realize this ability will be novel/surprising to some people, and this is meant to be a joke.

I don't do this not because I can't, but because I have no incentive to lie about who wrote/committed certain code.

[infinity0]

> all following commits are preserved (hash doesn't change), but that's essentially impossible.

Actually, you only need one brute-force (of the commit that you're changing); subsequent commits only refer to the parent hash, and here we're not changing the commit trees either.

SHA1 is already considered broken, so git really should switch to SHA256 soon. This whole "sha1 commit hashes are not for security" argument is mostly naive and bogus.

The only way it would be safe, is if (a) everyone set their GPG to default to SHA256 or above (older versions still default to SHA1) and (b) either (b.1) everyone signed every commit this way, or (b.2) everyone signed their tags this way and just before tagging, reviewed their local commits including commits not authored by them up to the previously trusted tag.

But if git defaulted to SHA256 or SHA512, then we wouldn't have to reason through the complex scenarios involving (b). Making something "too secure" is a good thing if it simplifies your security analysis and allows you to use your head for other productive things.

[shurcooL]

Good point, only need to brute the commit being modified to have it match the original hash.

To get a brief sense of how hard it is to do, one can look at a sample project like gitbrute [0] that tries to brute force the first n letters of a commit hash. It took someone 30 mins to brute first 8 hex letters (of 40) on a MBP [1] with that.

[0] https://github.com/bradfitz/gitbrute

[1] https://github.com/bradfitz/deadbeef/commit/deadbeefa1a98280...

[gre]

Why SHA-256 instead of SHA-3?

[infinity0]

No particular reason, I just picked that as the default choice in my head. SHA-3 also works, just less widely implemented atm. (Still waiting for a sha3sum command in coreutils).