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.
Git-blame-someone-else – Blame someone else for your bad code
21–30 of 68 posts
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…
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
#23And 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…
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
#24If 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
#25Earlier 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?
Re: Git-blame-someone-else – Blame someone else for your bad code
#26Earlier 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…
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…
Re: Git-blame-someone-else – Blame someone else for your bad code
#28Re: Git-blame-someone-else – Blame someone else for your bad code
#29Earlier 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?