I don’t like how GitHub changes my committer to them in the name of being Verified. I don’t care about it being Verified by GitHub (yes, even if it had always worked and not allowed spoofing).
It’s weird that GitHub has such a long history of cooperation with the Git project and yet just rewriting the committer is considered okay to them.
It's common practice to have the committer not match the author (especially in environments where only patches/diffs are sent). I can't imagine the git project having any issue with that, given that the author field stays retained (ignoring this bug ofc.).
I tried to do some more research on this. Unfortunately the search combination
> rewrite commit github verified
is so insanely SEO-poisoned by (1) StackOverflow questions about how to rewrite commits and (2) GitHub’s docs about regular (built-in Git commit verification) commit verification.
But I thought about it some more. And I guess them hijacking the committer on pull request merges is not that insanely bothersome. It’s their platform after all.
Just yet another reason to not interact with forges in a way that affects Git itself.
But another thing I’ve noticed is that sometimes my committer becomes the stupid initial (legacy) email I used to sign up there. Why in the hell? My current email is already registered there. But I tested this now and at least I got the option to merge as one of my addresses. So I guess it was fixed?
> It's common practice to have the committer not match the author
When the committer and author are different people. And apparently when GitHub tries to insert itself as a pseudo-person.
I expected that my own actions would be tied to my own identity on GitHub. Not for them to shoehorn GitHub Verified™ into commit objects that I create through clickity-clacking around their UI. But it is after all their UI and they can poison commits however they like since they create it (i.e. I didn’t create it and send it to them; then I would have noticed if they tried to rewrite it). So shame on me.
> especially in environments where only patches/diffs are sent
Clearly doesn’t apply here.
> I can't imagine the git project having any issue with that, given that the author field stays retained (ignoring this bug ofc.).
Given that they don’t use GitHub for anything directly related to Git (PRs and such) and that they have their own way of indicating code provenance: No, I guess they have no reason to care. (Other than in spirit.)
But it matters in general (in spirit) that if I pick up some patch by Jack Cooper and apply it then the committer is me. Not outlook.com. Or whatever program did it for me.
The commit object has a few metadata fields. I’ve never seen anyone say, “Oh yeah sure, just use that field for whatever it’s not like it matters anyway”.
If you contribute to the Git project itself, or other major git-using projects like the Linux kernel, you’ll get completely accustomed to having your commits committed by someone else.
Having a long history of cooperation with the Git project should only increase your confidence in doing that.
Also, don’t use the web UI to commit if you want to sign with your key, simple.
I know that Junio C Hamano applies all patches himself to git.git and thus is the committer on all commits.[1] That is how Git works when picking out patches from a mailbox.
The are all committed by people, not some middle man program.
Just like I can click the big merge button myself and then it is committed by... oh by mr noreply?
Try to find some committer or author in the git.git project that has a name like “Verified By Yahoo! <jibber jabber hash nonense>”? Good luck. (Almost like that kind of forge silliness was never accepted into any of their workflows... yet they are somehow very comparable, in your mind.)
This is like trying to explain to some Outlook representative that no one cares if they “verify” emails that go through them with some proprietary DKIM headers that only they know and care about.[2] “Well actually, if you understood how email headers work then you would see that it is not at all unlike......”
> Also, don’t use the web UI to commit if you want to sign with your key, simple.
Thank you for the tip.
[1] With the few pull request by way of email exceptions
You may have pressed the button, but the actual commit action was done by GitHub's infrastructure, hence they are listed as committer. Think of it as an acknowledgment that maybe they were hacked and made to do the commit even if you didn't want it.
If you want to do the commit yourself, you can run `git merge` locally and push the result. They won't touch the commit (including the committer) in that case, because the commit hash must never change. I'm not sure if they track who did the push (or even what the sensible value would be if two people pushed the same commit to two different forks).
The web-flow signing system is for users’ convenience in places where it’s not feasible to sign the commit with their own private key: commits made in the web interface or on an ephemeral GH-provisioned VM (codespace). For the latter, you are free to send your own private key to your codespace so you can sign your own commits but GitHub cannot because they don’t have your private key and don’t want to have it. Defaults matter and signed commits are important.
As a sibling notes, this use case and similar ones is the reason the committer field exists as distinct from the author field. I think a $10K bounty for this bug speaks to how seriously they stand behind the fact that they will only sign and mark as verified commits whose author field matches an authenticated user.
> The web-flow signing system is for users’ convenience in places where it’s not feasible to sign the commit with their own private key:
Who signs all their commits? Joey Hess maybe? There are certainly others. But I’ve never seen anyone make a case for this. In fact only negative cases since it just encourages you to automate your signing process, which many are not comfortable with.[1]
I’m not important enough to sign anything.
On Bitbucket we push the big merge button and out comes a commit with the correct person attributed to it.[2] Even Atlassian manages to do this the correct way.
> For the latter, you are free to send your own private key to your codespace so you can sign your own commits but
Yeah GPG/SSH sign commits... who cares. Most people don’t.
> Defaults matter and signed commits are important.
I don’t care about your opinion.
I wouldn’t mind if this was an option that I could opt out of. (I’m wondering out loud, not asking you or anyone else.) I just haven’t heard of it yet.
I’m a Git user after all so I’m used to changing bad defaults.
> As a sibling notes, this use case and similar ones is the reason the committer field exists as distinct from the author field.
Quite a leap to go from attributing emailed-around patches to the correct author while also maintaining the committer (like the maintainer) to what looks equivalent to Norton Antivirus junk output stuffed 40 lines into someone’s email signature.
> I think a $10K bounty for this bug speaks to how seriously they stand behind the fact that they will only sign and mark as verified commits whose author field matches an authenticated user.
“I think the price they put on this SPOOFING vulnerability speaks to how serious they are about verified commits”, they said without irony.
“Sent from my GitHub”, ah they all felt at-ease immediately... wait the same platform that had a spoofing vulnerability?
[1] Well, allegedly. I have never signed anything so I don’t know.
[2] They committed it too. Or wait. Was that the merge button?
It’s weird that GitHub has such a long history of cooperation with the Git project and yet just rewriting the committer is considered okay to them.