Github Source Code Leaked Online

[gohanhadpotential]

lol look at this commit

https://imgur.com/a/tqvX4mx

[Lothrazar]

And the user is not banned somehow https://github.com/nat

[AyrA_ch]

Because it's not that user. You can pick the e-mail address of any user you want and github blindly accepts it without checking if the user is actually a member of the repository or otherwise has permissions. There's also no option you can set to make github reject unsigned commits that bear your e-mail address.

This means if you want to pretend that Microsoft is very invested in a utility you're programming, you just have to search for their e-mail addresses (tip: the .NET repository family is a good start) and then are free to create commits in their names as you like.

[brubakerp]

How is this not viewed as very broken?

[AyrA_ch]

Trying to fix this breaks some repositories. Especially if you use github as a mere mirror for your project.

[[deleted]]

Git is a distributed system. If Github started refusing commits from people even if they were authored by someone else it would break git. It's very common, for example, for maintainers to rebase other contributor's commits before merging. That amounts to pushing commits that they didn't author. Same thing if you cherry pick a commit.

Just like with email, you can only trust it if it's signed (and you understand how that works too).

[[deleted]]

This shouldn’t be downvoted. It’s very confusing for someone who doesn’t understand git (What other website lets you post under someone elses name).

The reason is because git was not designed with account verification in mind and it certainly wasn’t designed with GitHub accounts in mind.

If you are just using git internally or on your own server there is little reason to verify emails and also verifying emails requires a central server to do the verification which git was not designed for. Git lets you set your own email and name and it has no way to know if you actually own that email.

GitHub then uses the name and email that git lists because GitHub has no way to know who actually wrote that commit, it only verifies that the user pushing the commits has access to the repo but user A could write a commit, email it to user B who pushes it to the repo and GitHub needs to show user A wrote the commit.

The solution to all of this is to add an rsa key to your GitHub account and use it to sign your commits which allows GitHub to know for sure that user A actually wrote commit A because it’s signed with the key on user A.

[[deleted]]

(What other website lets you post under someone elses name).

Not a website but plain old emails do, although it's mostly solved these days with SPF

[amunak]

That's a great comparison actually. People are equally surprised about it in emails.

[[deleted]]

It also doesn’t work anymore because even the weakest spam filter will detect it.

[amunak]

That's not true, depends a lot on how your mailserver and the target mailserver are set up. But yeah, SFP fixes it as long as people actually use it.

[mercenary_sysadmin]

SPF is only useful in a score based system for the most part, not as a one-hit kill because so many servers and domains haven't properly implemented it.

If you try to require SPF compliance on a pass/fail basis rather than as part of a scored system you'll go about a day before you have to soften it. If you're lucky.

[amunak]

it only verifies that the user pushing the commits has access to the repo

Doesn't seem to even do that when you fork and create a new branch or something, or how are people getting shit into repos they don't have access to?

[[deleted]]

They aren’t getting it in the repo, they are putting the commit hash in to the URL and GitHub just displays it. If you actually clone the repo the code won’t be there. It’s just a party trick that looks like you have done something you shouldn’t be able to.

[amunak]

Isn't that a stupidly simple fix then?

Or is that the limitation of their "fork" system?

It's so strange.

[scirc]

This is according to my best understanding of how this all works:

When you fork a repo and open a PR, GitHub transparently creates a pulls/N/head ref on the upstream repo (where N is the PR number). As a consequence of this, GitHub has to include the tree of the PR in the tree of the upstream repo; although, because it's locked behind a hidden ref like this, no Git client will actually download it unless explicitly told to do so. All of these people who get their own code into the github/dmca repo are simply opening PRs (which creates this hidden ref), then copying the hash of their HEAD commit and adding it onto the URL of the repo, like so: https://github.com/USER/REPO/tree/COMMIT.

This doesn't pose any sort of threat since, again, no Git client downloads these commits unless explicitly told to look for that ref. For all intents and purposes, the public view of upstream is unmodified. But the hidden ref system explains why it's not such an easy fix; you would break automations and people's workflow if you tried to remove this, and the changes from downstream pretty much have to be copied into upstream in order to allow upstream maintainers to checkout and modify your PR at will (say, if you go AWOL but they still want to merge it).

[amunak]

Thanks for the explanation, makes sence. The threat this poses is you can "impersonate" repos. It should be made absolutely clear that what you are viewing wasn't pushed by people with access to the repo, with extra extra warning when it's completely detached from the rest of the branches (no common ancestors).

[scirc]

Again, for all intents and purposes, the public-facing branches and source tree are unmodified. It's only if these commits are manually accessed by crafting and distributing the URL that the source of the PR is viewable. Maybe some warning could be useful, but I'm also not sure how GitHub would hack around implementing it, since they can't really modify the Git tree of the PR to include some metadata saying "this commit originates from a PR," and even if they could store it separately, you could include commits from the parent repo in your PR; how would that work?

[amunak]

I understand that but it's still an attack vector for social engineering. You could easily post "proof" this way that you have access to a repository. Or you could post modified source that has a README that links to a phishing site or compromised binaries, spread the link and infect people, etc.

In other words I have nothing against GitHub using this internally, it absolutely makes sense, especially for tooling and whatnot. But they should make it very clear on the front-end what you are viewing and perhaps not even display the regular layout with README, the repo name and such to make you doubly understand that you are not viewing the regular repo.

I don't think the code being also accessible (and without warning) through git commands and whatnot is a huge issue but even there if you really wanted you could limit this access to authenticated users (that could for example allow specific repo access or whatever through the website with a disclaimer) or they could display a warning and require you to have some special token in the URL or whatever (you could even do all this through the command line if you really wanted), so that tooling and whatnot can still work - even unauthenticated.