Live data from Hacker News

Git-blame-someone-else – Blame someone else for your bad code

github.com

21–30 of 68 posts

Re: Git-blame-someone-else – Blame someone else for your bad code

#21
post #11
post #9

Earlier quoted context omitted.

It's a bit worrying that GitHub will happily associate someone's face on a commit that they didn't write: https://github.com/jayphelps/git-blame-someone-else/commit/e... 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…

Worrying and potentially libelous. Some countries (e.g. UK) have strict libel law, and by using this you could get Github in trouble for publishing libelous material. Of course, this has always been possible with git.

Though since GitHub does not have an office in the UK and in the US is protected from foreign defamation judgements under the SPEECH Act, it probably doesn't have much to worry about.

Re: Git-blame-someone-else – Blame someone else for your bad code

#22

(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=a@a.com GIT_COMMITTER_DATE=2006-01-02T15:0…

> 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.

Re: Git-blame-someone-else – Blame someone else for your bad code

#23
post #9

And this is why I pgp sign all my commits. :-P

It's a bit worrying that GitHub will happily associate someone's face on a commit that they didn't write: https://github.com/jayphelps/git-blame-someone-else/commit/e... 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…

Alternatively, they could provide some sort of on-page indication of a credentials/e-mail mismatch, i.e. detect and publicly report when the HTTPS/SSH credentials used for a `git push` aren't associated with a verified e-mail address matching the commit's `user.email`.

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.

Re: Git-blame-someone-else – Blame someone else for your bad code

#24
Hell, I can do _all_ my work as somebody else with "git config user.name" and "git config user.email".

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.

Re: Git-blame-someone-else – Blame someone else for your bad code

#25
post #14
post #12

Earlier quoted context omitted.

There are so many things that GitHub could easily do, but don't... Makes me wonder what they actually do.

You mean besides developing and operating one of the best services on the web?

Best as in market share, but certainly not best by it's own merits. (ie there is better git management software)

Re: Git-blame-someone-else – Blame someone else for your bad code

#26
post #9

Earlier quoted context omitted.

It's a bit worrying that GitHub will happily associate someone's face on a commit that they didn't write: https://github.com/jayphelps/git-blame-someone-else/commit/e... 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…

Alternatively, they could provide some sort of on-page indication of a credentials/e-mail mismatch, i.e. detect and publicly report when the HTTPS/SSH credentials used for a `git push` aren't associated with a verified e-mail address matching the commit's `user.email`. 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…

But isn't it somewhat reasonable that I push someone else's commit? Say I want to rewrite an old commit, and then force push that, then all the commits after the rewritten commit by other people would effectively be pushed by me.

Or consider the common case where the public repository on Github is just a mirror of an official repository somewhere else -- then commits from a bunch of people would all be pushed by whoever is responsible for keeping the repos in sync.

But maybe Github could just add some kind of a "pushed by" label that identifies the Github user who pushed the commit?

Re: Git-blame-someone-else – Blame someone else for your bad code

#27

(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=a@a.com GIT_COMMITTER_DATE=2006-01-02T15:0…

> 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…

Why SHA-256 instead of SHA-3?

Re: Git-blame-someone-else – Blame someone else for your bad code

#29
post #14
post #12

Earlier quoted context omitted.

There are so many things that GitHub could easily do, but don't... Makes me wonder what they actually do.

You mean besides developing and operating one of the best services on the web?

Best in what sense? Bitbucket does everything Github does, plus gives free private repos. GitHub is just more widely used.
Post reply on HN