GitHub Commit Forgery(spoof.krypt.co)
spoof.krypt.co
GitHub Commit Forgery
https://spoof.krypt.co/?hns=1
49 comments
This is nothing github specific. It will work with any git repository. Author is just a text attached to commit. Anybody can set it to anything.
You don't even need to edit ~/.gitconfig file. Just set GIT_AUTHOR_NAME / GIT_AUTHOR_EMAIL / GIT_AUTHOR_DATE env variables to anything you want. See https://git-scm.com/book/en/v2/Git-Internals-Environment-Var... for more variables.
You don't even need to edit ~/.gitconfig file. Just set GIT_AUTHOR_NAME / GIT_AUTHOR_EMAIL / GIT_AUTHOR_DATE env variables to anything you want. See https://git-scm.com/book/en/v2/Git-Internals-Environment-Var... for more variables.
I found this out when I was migrating code from hg in google code (now archived) to github. The source commits didn't have valid email addresses so they didn't work very well with git and github, so I just rewrote them to something else. There's no special checks that a commit came from the owner of an email address, and there's no way to prove it did/didn't.
Take commit metadata with a grain of salt.
Take commit metadata with a grain of salt.
Note that this is not a selfless public service announcement, it's a marketing campaign for a commercial product.
This is true but on the other hand anyone making a serious effort to fix the raging dumpster fire which is PGP usability deserves some kudos. Most people who turn GPG signing on in Git seem to turn it off after hitting one of the many UX failures.
I don't get it - of course this can be done. The easiest way is to use
git commit --author="Some Name <[email protected]>"
Or commit to the future:
git commit --author="Zager Evans <[email protected]>" --date="Fri Aug 3 14:00 2525 +0000"
There is no fundamental difference between a commit message and the commit author, its just some meta information attached to the commit. It's up to whoever is responsible to merge pull requests to check if this commit is actually coming from the person you think it is. Signed commits are one option, others would be to send the commit as a patch via mail (also possibly signed), or to open a pull request as a logged in user on an auxiliary meta-platform (which is exactly what Github is).
git commit --author="Some Name <[email protected]>"
Or commit to the future:
git commit --author="Zager Evans <[email protected]>" --date="Fri Aug 3 14:00 2525 +0000"
There is no fundamental difference between a commit message and the commit author, its just some meta information attached to the commit. It's up to whoever is responsible to merge pull requests to check if this commit is actually coming from the person you think it is. Signed commits are one option, others would be to send the commit as a patch via mail (also possibly signed), or to open a pull request as a logged in user on an auxiliary meta-platform (which is exactly what Github is).
Git is cryptographically secure, but it's not foolproof.
However signing a single commit verifies the parent commits (similar to the blockchain) so it isn't necessary for every commit.
Signing tags and commits is great, but if you decide to use this in your normal workflow, you’ll have to make sure that everyone on your team understands how to do so. If you don’t, you’ll end up spending a lot of time helping people figure out how to rewrite their commits with signed versions. Make sure you understand GPG and the benefits of signing things before adopting this as part of your standard workflow.
However signing a single commit verifies the parent commits (similar to the blockchain) so it isn't necessary for every commit.
Signing tags and commits is great, but if you decide to use this in your normal workflow, you’ll have to make sure that everyone on your team understands how to do so. If you don’t, you’ll end up spending a lot of time helping people figure out how to rewrite their commits with signed versions. Make sure you understand GPG and the benefits of signing things before adopting this as part of your standard workflow.
Git offers the _option_ to sign commits. Git itself makes no guarantees that a commit's author is who it's listed to be, unless you use signed commits.
Signing a commit does not verify parent commits in the way I think you think it does. It does give the guarantee of 'These are the commits that are the basis of my commit', but that is only worth as much as what your signature actually conveys. Your signature certainly conveys you authored your commit, but it doesn't guarantee that the parent commit was authored by who was listed as the author.
Signing a commit does not verify parent commits in the way I think you think it does. It does give the guarantee of 'These are the commits that are the basis of my commit', but that is only worth as much as what your signature actually conveys. Your signature certainly conveys you authored your commit, but it doesn't guarantee that the parent commit was authored by who was listed as the author.
[deleted]
I do this for a year now with my gpg key, haven't had a moment where this was of any use. yet.
Signing a commit does "sign" all previous commits, but it doesn't verify that they are actually yours, you still have to manually do that. If someone slips in a "fake commit" either directly on to your machine, or does it to remote and you pull it down and commit and sign a tag, you won't get any kind of notification there is an issue.
IMO it's better to sign all commits, as then it gets you in the habit of knowing how it's done, you are less likely to make mistakes while doing it, and you can add tooling that will sound alarms at the first unsigned commit.
It does leave you more vulnerable to keyloggers, and gives more instances where your key is decrypted and used, but I personally think that's a better problem to have rather than having to manually verify every single commit isn't forged before you sign and tag.
IMO it's better to sign all commits, as then it gets you in the habit of knowing how it's done, you are less likely to make mistakes while doing it, and you can add tooling that will sound alarms at the first unsigned commit.
It does leave you more vulnerable to keyloggers, and gives more instances where your key is decrypted and used, but I personally think that's a better problem to have rather than having to manually verify every single commit isn't forged before you sign and tag.
Is Git cryptographically secure?
Linus certainly doesn't see this as a goal of Git. Against what threats does the cryptography protect? Has anyone published the threat model of Git? Things I worry about:
1. Can I reorder commits without access to secret keys?
2. What if one secret key is compromised, do I have to resign all my old commits with the new secret key? How do I do that?
3. How do I ensure my list of authorized keys is the same as yours?
4. Can I easily detect that my code signing key has been compromised?
5. How do you prevent a Pull Request that contains a unittest that when run exfils your keys, opens a shell, injects source code or backdoors git?
Linus certainly doesn't see this as a goal of Git. Against what threats does the cryptography protect? Has anyone published the threat model of Git? Things I worry about:
1. Can I reorder commits without access to secret keys?
2. What if one secret key is compromised, do I have to resign all my old commits with the new secret key? How do I do that?
3. How do I ensure my list of authorized keys is the same as yours?
4. Can I easily detect that my code signing key has been compromised?
5. How do you prevent a Pull Request that contains a unittest that when run exfils your keys, opens a shell, injects source code or backdoors git?
> Is Git cryptographically secure?
Not right now, because it still uses SHA-1. But apart from that, the answers are:
> 1. Can I reorder commits without access to secret keys?
No, because a hash of some commit data is what’s signed and the parent is part of that
> 2. What if one secret key is compromised, do I have to resign all my old commits with the new secret key?
No, just make a new commit on top with the new key explicitly explaining that you trust the old stuff
> 3. How do I ensure my list of authorized keys is the same as yours?
I don’t understand that question. Can you expand on it?
> 4. Can I easily detect that my code signing key has been compromised?
No, and the same goes for pretty much anything else that can be compromised.
> 5. How do you prevent a Pull Request that contains a unittest that when run exfils your keys, opens a shell, injects source code or backdoors git?
You read it before you run it.
Not right now, because it still uses SHA-1. But apart from that, the answers are:
> 1. Can I reorder commits without access to secret keys?
No, because a hash of some commit data is what’s signed and the parent is part of that
> 2. What if one secret key is compromised, do I have to resign all my old commits with the new secret key?
No, just make a new commit on top with the new key explicitly explaining that you trust the old stuff
> 3. How do I ensure my list of authorized keys is the same as yours?
I don’t understand that question. Can you expand on it?
> 4. Can I easily detect that my code signing key has been compromised?
No, and the same goes for pretty much anything else that can be compromised.
> 5. How do you prevent a Pull Request that contains a unittest that when run exfils your keys, opens a shell, injects source code or backdoors git?
You read it before you run it.
Really appreciate your answers. I've wondered about this stuff for a while but never had the time to read through the Git source code.
>No, because a hash of some commit data is what’s signed and the parent is part of that.
How does this work with cherry picks or rebases? Would it just be authorized by the key of the person doing the rebase and lose the authentication of the original commits? How would this complicate say forensics investigation attempting to understand how authored a backdoor?
>I don’t understand that question. Can you expand on it?
Lets say I am a member of an organization and I am syncing a git repo for the first time. How do I ensure that the code I am getting was only authored by members of that organization? Who does the work of adding new keys for new members, revoking old keys when employees leave or keys are compromised? How does everyone agree on this key set?
> No, and the same goes for pretty much anything else that can be compromised.
I agree to determining key compromise is impossible but the detection of use of compromised keys in a suspectious manner is certainly possible. Consider a chain of one-use keys where each key is only used once per commit and then deleted. Using a key twice triggers alarms and emails.
>You read it before you run it.
You should read it before you run it however everyone makes mistakes and detecting underhanded programming techniques is hard. One could imagine a source code system that would warn users that the code they are about to run has not been authored by anyone in their organization.
>No, because a hash of some commit data is what’s signed and the parent is part of that.
How does this work with cherry picks or rebases? Would it just be authorized by the key of the person doing the rebase and lose the authentication of the original commits? How would this complicate say forensics investigation attempting to understand how authored a backdoor?
>I don’t understand that question. Can you expand on it?
Lets say I am a member of an organization and I am syncing a git repo for the first time. How do I ensure that the code I am getting was only authored by members of that organization? Who does the work of adding new keys for new members, revoking old keys when employees leave or keys are compromised? How does everyone agree on this key set?
> No, and the same goes for pretty much anything else that can be compromised.
I agree to determining key compromise is impossible but the detection of use of compromised keys in a suspectious manner is certainly possible. Consider a chain of one-use keys where each key is only used once per commit and then deleted. Using a key twice triggers alarms and emails.
>You read it before you run it.
You should read it before you run it however everyone makes mistakes and detecting underhanded programming techniques is hard. One could imagine a source code system that would warn users that the code they are about to run has not been authored by anyone in their organization.
> How does this work with cherry picks or rebases? Would it just be authorized by the key of the person doing the rebase and lose the authentication of the original commits?
Yes.
> ⋮
Sounds like your organization will need to put a lot of new stuff on top of PGP and Git, then.
Yes.
> ⋮
Sounds like your organization will need to put a lot of new stuff on top of PGP and Git, then.
Git code signing is as easy as adding -S option when making a commit. Why do we need a thrid-party stuff?
Hey HN -- one of the creators here. I saw a few people mention this in the comments and want to re-iterate: this is NOT a bug on GitHub. This is a feature of Git that GitHub has to support because we often need to push commits on behalf of other users.
However -- this does illustrate a clear reason why it sometimes makes sense to PGP-sign your releases/commits.
However -- this does illustrate a clear reason why it sometimes makes sense to PGP-sign your releases/commits.
Yeah, I figure you all know that :) I just think calling it "forgery" / "fraudulent" makes it sound like a Git/GitHub vulnerability. It's a feature that depends on trust and goodwill, and the fact that trust can be abused isn't interesting.
For instance, if I wrote "Hey HN, one of the creators here" when I'm not, people wouldn't call that "HN comment forgery" - they'd just call it regular lying.
For instance, if I wrote "Hey HN, one of the creators here" when I'm not, people wouldn't call that "HN comment forgery" - they'd just call it regular lying.
>It's a feature that depends on trust and goodwill
Such features can be a vulnerability, a vulnerability does not have to be an accident
>the fact that trust can be abused isn't interesting
As a security researcher it is interesting to me but clearly YMMV
Such features can be a vulnerability, a vulnerability does not have to be an accident
>the fact that trust can be abused isn't interesting
As a security researcher it is interesting to me but clearly YMMV
I think the title should be changed from "GitHub Commit Forgery" to "Git Commit Forgery".
Also I looked at your actual product (a U2F implementation that forwards things to your phone) and it seems pretty cool! Definitely more secure than TOTP. You should Show HN that :-)
This is just propaganda.
The title is misleading, the text itself is sensationalist and over promotting their own product.
Git authors are simply names associated to commits, it's not supposed to authenticate anyone, so talking "forgery" is just nonsense.
Any repository owners worried about the authenticity of the commits should allow only signed commits. This is available in all major git platforms AFAIK.
The title is misleading, the text itself is sensationalist and over promotting their own product.
Git authors are simply names associated to commits, it's not supposed to authenticate anyone, so talking "forgery" is just nonsense.
Any repository owners worried about the authenticity of the commits should allow only signed commits. This is available in all major git platforms AFAIK.
This is a remarkable landing page. Fantastic.
1. Clear problem every developer has (most don't even know !!)
2. Inform on how to solve the problem
3. Offer the convenient solution.
Wow.
1. Clear problem every developer has (most don't even know !!)
2. Inform on how to solve the problem
3. Offer the convenient solution.
Wow.
It's also remarkable because it's fear-mongering. It's not a "problem," and most developers would be mad if they stopped getting credit for their pull requests in projects using a rebase workflow, which is what their "solution" would require. (See my other comment for details.)
It's not just fear-mongering, it's marketing for a product. (And IMHO somewhat sleazy marketing.)
>It's not a "problem,"
To me it is a problem and I'm glad they are pointing it out. I suspected this was possible but wasn't sure, now I know for sure.
To me it is a problem and I'm glad they are pointing it out. I suspected this was possible but wasn't sure, now I know for sure.
Technically, it is the same "problem" as falsely writing "this proofs P = NP" into the commit message. It's just free text, you can put whatever you want there (as long as the email address is formatted correctly, I guess).
Edit: Github actually marks verified commits in their GUI: https://help.github.com/assets/images/help/commits/gpg-signe...
Edit: Github actually marks verified commits in their GUI: https://help.github.com/assets/images/help/commits/gpg-signe...
I will admit that GitHub formats the commit in a way where it looks like the commit author may have been verified in some way (because it's linked to a GitHub account, and approximately no other type of online service permits posting things from an account without actually being from that account - the PGP keyservers are the only other one I can think of!), and the content of commit messages don't look like they're endorsed by GitHub.
I'm not sure if there's an easy way in the UI to demonstrate unverified/verified, though. Even a small broken-lock icon would imply that something is wrong when it's not really wrong, it's just common practice for this to be entirely based on trust.
Perhaps it would help to show the verified identity of the user who pushed the commit to GitHub alongside the unverified author?
I'm not sure if there's an easy way in the UI to demonstrate unverified/verified, though. Even a small broken-lock icon would imply that something is wrong when it's not really wrong, it's just common practice for this to be entirely based on trust.
Perhaps it would help to show the verified identity of the user who pushed the commit to GitHub alongside the unverified author?
It reminded me of this interesting behavior of keyservers, that is by design but still surprising - anyone can add UIDs to any key: https://bitbucket.org/skskeyserver/sks-keyserver/issues/41/w...
It does emphasize something, that isn't a "huge" issue for some, but they way the portray it on the page, really drives their sales pitch.
Yes I do think this is a tremendous PR campaign.
Is this working? I just tried it and it generates a commit hash that leads to a 404 page[1]. I haven't looked into what the code is doing, but for it to claim that it stole my identity is very misleading.
[1] - https://github.com/git-forge/fraudulent/commit/a0a2c80140bae...
[1] - https://github.com/git-forge/fraudulent/commit/a0a2c80140bae...
It looks like there's some intermittent failure with the high number of incoming requests -- sorry! Try again and it should work :)
Most git servers have an option to only allow commits to go through if the ssh key that is pushing the commit matches the SSH key associated with the account of the "Author" field. Easier to implement than enforcing PGP signing.
Sounds impractical in the case of GitHub though. If I create a repo, you fork my repo, I push some commits to mine, then you pull from mine and author some more commits and then I delete my repo then you can’t push.
This didn't quite work for me since I had my github username changed (caleb-davenport to calebdavenport) about a year ago. It used my old username instead.
https://github.com/git-forge/fraudulent/commit/f9f2b8b6f2711...
https://github.com/git-forge/fraudulent/commit/f9f2b8b6f2711...
Not sure how gitlab handles the avatar, but in practice this doesn't matter internally in a FLOSS project:
"The commit that broke something is attributed to Sojourner Truth. That's you, right?"
"Yes, that's me."
However, a centralized identity in a global namespace that merely wraps around arbitrary state entered into a local instance of git instance is not gonna go good.
"The commit that broke something is attributed to Sojourner Truth. That's you, right?"
"Yes, that's me."
However, a centralized identity in a global namespace that merely wraps around arbitrary state entered into a local instance of git instance is not gonna go good.
forged commit: https://github.com/git-forge/fraudulent/commit/95321ee7b3e25...
authentic commit: https://github.com/bsdlp/packagebot/commit/c7cd115357f51e8e1...
you can use a gpg key to sign your commits and tell github about your public key so they can add a verified badge in the commit log. really only useful if github can enforce authenticity when pushing to repos...
authentic commit: https://github.com/bsdlp/packagebot/commit/c7cd115357f51e8e1...
you can use a gpg key to sign your commits and tell github about your public key so they can add a verified badge in the commit log. really only useful if github can enforce authenticity when pushing to repos...
[deleted]
Ambiguous title. I read it as "Github, the company, commits forgery."
[deleted]
Wow.
Real c0d3rs don't need that, only git-vain https://github.com/will/git-vain
If Git implemented something with commit signing as a matter of course, this functionality would be broken. I couldn't directly attribute the commit to you; it would be signed with my key instead, because your original signature won't be valid. I could of course put your name in the commit message, but then the "forgery" problem arises again: I can just put anyone's name right there, of course.
The current system ensures that you get credit for your work (and it's machine-parseable credit, so it shows up in your GitHub profile's contribution history) when someone rebases a commit you wrote, instead of the project maintainer getting credit.