3 ms·

I wouldn't say it was a bug in GitHub's application that allowed someone to impersonate Nat, it's just that the author of the commit (which can be changed easil

by thdc 6y ago

I wouldn't say it was a bug in GitHub's application that allowed someone to impersonate Nat, it's just that the author of the commit (which can be changed easily/set manually in git) matched his name/email. How many people can actually push to that repo? I wonder if it would be easy to figure out who actually did it...

resynth1943 6y ago
I'd still say it was a bug in GitHub, to be frank. This definitely shouldn't be allowed.
- lights0123 6y ago
  Currently, requiring signed commits (the only way to prevent this) would be a massive breaking change, as I would guess that 90%+ of GitHub users don't use GPG to sign their commits. However, they may be able to make that opt in, although it could very well break a ton of automated scripts and would completely break things like squash merging or rebasing by a maintainer.
  - resynth1943 6y ago
    I was thinking more along the lines of simply checking the email of the (real) commit author against the "email" used in the Git commit. Would this not be possible?
    - TheDong 6y ago
      That would break quite a few workflows. For example, if I were to 'git clone' a project currently on gitlab, create a github repo for it, add that origin, and push... Well, that pushes commits authored by every single person who ever committed to that other repository. Do I have to make all of them re-push only their own commits in order? Can robots not mirror repositories anymore? What about commits authored by people without github accounts? There's also the obvious issues of me merging a coworker's commit into my branch, or cherry-picking, or rebasing a third-party contributor's commits to update them before merge. I think the case of "push an existing repo with N authors to a new repo" is a really compelling reason though for why that sort of "you can only push commits with your email" thing would not work.
  - semiquaver 6y ago
    https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/about-required-commit-signing https://docs.github.com/en/free-pro-team@latest/github/admin...
- minitech 6y ago
  It’s fundamental to the way Git works. Signed commits are a thing when you need verified authorship.
  - r-w 6y ago
    I feel like anyone would expect this to be guarded against though. There may not be a particular reason to "need" it, but the fact it's even possible is ridiculous.
    - kelnos 6y ago
      Consider that I can pull a branch from someone else's repo (even if that repo is not on GitHub), merge it into my own fork of something, and then push all of that to GitHub. All of the commits in that branch I pulled, regardless of who committed them (not me, presumably) should still be attributed to their original authors, and that's what will happen on the fork I push to GH. This is fundamentally necessary to how the distributed nature of git works. If you want to assure others that commits really came from you, you need to sign your commits. But so few people do that, so the default is just to trust that commits are from who they say they are. Perhaps GitHub could have a feature whereby you could toggle a setting so they won't link a commit to your GH user account unless it's signed by you. That still comes with its own problems (like say you submit a PR to some project, but the maintainer rebases master onto your branch before merging, which will kill the signatures). But still, signing every commit is not really necessary. I personally only sign release tags, which implicitly cover all commits leading up to those releases.
lights0123 6y ago
If you open a PR to a GitHub repo, all of its commit hashes become available to the parent repo. This is what most likely happened here (can't confirm due to the fact that it's already deleted), and did happen when the youtube-dl source became available from the dmca repo.
stock_toaster 6y ago
Did this commit actually appear in that repo history timeline? Github does the thing where a cloned repo shares the object space with all repos of the origin, so you can use the same commit sha1 on any of the repos. All someone would have to do is clone the repo, make the commit to their clone, then share the link with the sha1 in the origin repo. The sha1 blob may not actually appear in the main repo timeline.

by thdc 6y ago

resynth1943 6y ago

I'd still say it was a bug in GitHub, to be frank. This definitely shouldn't be allowed.

lights0123 6y ago
Currently, requiring signed commits (the only way to prevent this) would be a massive breaking change, as I would guess that 90%+ of GitHub users don't use GPG to sign their commits. However, they may be able to make that opt in, although it could very well break a ton of automated scripts and would completely break things like squash merging or rebasing by a maintainer.
- resynth1943 6y ago
  I was thinking more along the lines of simply checking the email of the (real) commit author against the "email" used in the Git commit. Would this not be possible?
  - TheDong 6y ago
    That would break quite a few workflows. For example, if I were to 'git clone' a project currently on gitlab, create a github repo for it, add that origin, and push... Well, that pushes commits authored by every single person who ever committed to that other repository. Do I have to make all of them re-push only their own commits in order? Can robots not mirror repositories anymore? What about commits authored by people without github accounts? There's also the obvious issues of me merging a coworker's commit into my branch, or cherry-picking, or rebasing a third-party contributor's commits to update them before merge. I think the case of "push an existing repo with N authors to a new repo" is a really compelling reason though for why that sort of "you can only push commits with your email" thing would not work.
- semiquaver 6y ago
  https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/about-required-commit-signing https://docs.github.com/en/free-pro-team@latest/github/admin...
minitech 6y ago
It’s fundamental to the way Git works. Signed commits are a thing when you need verified authorship.
- r-w 6y ago
  I feel like anyone would expect this to be guarded against though. There may not be a particular reason to "need" it, but the fact it's even possible is ridiculous.
  - kelnos 6y ago
    Consider that I can pull a branch from someone else's repo (even if that repo is not on GitHub), merge it into my own fork of something, and then push all of that to GitHub. All of the commits in that branch I pulled, regardless of who committed them (not me, presumably) should still be attributed to their original authors, and that's what will happen on the fork I push to GH. This is fundamentally necessary to how the distributed nature of git works. If you want to assure others that commits really came from you, you need to sign your commits. But so few people do that, so the default is just to trust that commits are from who they say they are. Perhaps GitHub could have a feature whereby you could toggle a setting so they won't link a commit to your GH user account unless it's signed by you. That still comes with its own problems (like say you submit a PR to some project, but the maintainer rebases master onto your branch before merging, which will kill the signatures). But still, signing every commit is not really necessary. I personally only sign release tags, which implicitly cover all commits leading up to those releases.

lights0123 6y ago

If you open a PR to a GitHub repo, all of its commit hashes become available to the parent repo. This is what most likely happened here (can't confirm due to the fact that it's already deleted), and did happen when the youtube-dl source became available from the dmca repo.

stock_toaster 6y ago

Did this commit actually appear in that repo history timeline? Github does the thing where a cloned repo shares the object space with all repos of the origin, so you can use the same commit sha1 on any of the repos. All someone would have to do is clone the repo, make the commit to their clone, then share the link with the sha1 in the origin repo. The sha1 blob may not actually appear in the main repo timeline.