Perhaps GitHub should only do this for signed commits or commits to the author's own repository or something.
GitHub also allows you to add anyone to a project without their consent (or has this changed?). This reminds me of the Facebook prank where someone added Mark Zuckerberg to a fake(?) pro-paedophile group.
It should be trivial for them to allow you to paste your pgp public key as you would your ssh public key, then place a nice little "verified" check mark next to commits that can be validated as having been signed with one of your associated private keys.
I reported this issue a long time ago to their security team, and got a really condescending "we're a collaborative community, it's not a problem, you obviously don't understand" type of response. Pretty frustrating.
Of course, this has always been possible with git.
It already has the keys set up and such.
I wrote a tutorial on a more effective (at least for me) solution to find the true author of a change: http://blog.andrewray.me/a-better-git-blame/
Unfortunately, adding -M and -C will quite badly increases the time to compute the blame. Both take an adjustable parameter (min number of characters to match), but I found I actually had to reduce it to catch all the lines in an example of the A.cpp -> A-star.cpp move I did yesterday.
Blame follows renames in most cases (unless you're doing something like creating a new file with the same name as the renamed one in the same commit), and you can use the -w flag to ignore whitespace changes.
[1] https://news.ycombinator.com/item?id=11049993
Apparently it will be obvious to folks that this has occurred.
Being a dvcs, you create atleast one commit on your local repo before pushing to a remote. That one (or more) commit can be changed to point at anyone and pushed.
The only exception to this is if someone else has not pulled into their private repo any changes at or before the commit you changed.
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=a@a.com GIT_COMMITTER_DATE=2006-01-02T15:04:05Z git commit --author='a <a@a.com>' --date 2006-01-02T15:04:05Z
I don't do this not because I can't, but because I have no incentive to lie about who wrote/committed certain code.
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.
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...
If that's really a genuine concern, then a) you are working with a big bag of dicks and b) there are _way_ worse things that person can do with write access to the repository than masquerade as somebody else.
I like this! Thank you
Not rewriting history, I still have this little script called fakecommit[0] lying around I have used in the past to commit stuff under other people's names.
[0]: https://github.com/winks/dotfiles/blob/cfd9d994d0bcd7510203a...
and in the only case this would work, i.e. nobody has that commit yet, you could just have commited as that person. nothing new or interesting.
now, github being garbage and not accounting for PGP signatures, now this is something else.