How is possible that someone like this exists in GitHub

I thought it was against the rules of the service to use this as a platform for host the binaries.

is this valid in the t&c?


Hello, welcome to the GitHub Support Community! I can see the confusion regarding this repository and GitHub’s Terms and Conditions; this one slightly confuses me as well. According to GitHub’s documentation, users may create releases to distribute necessary binaries and installers for the project in question. However, I do not know if the source code for those binaries is explicitly required to be present in the same repository.

I’m going to mention @angela-crist in this thread so we can figure out the correct solution to this issue! Thank you for letting us know about this repo!


Hi there @recox :wave:

Thanks so much for raising this and @gisgar3 for keeping us engaged. We do have an existing ticket open with similar reports for that repo. We’ve initiated an escalation process to get additional eyes on.

I’ll report back once there’s more to share.


I think GitHub should go further in its restrictions on binaries and releases - only binaries built by GH from the source in the repo should be hosted.

One can start a project, have some benign source code while uploading malicious binaries.
I think we kind of trust that if it’s on GH it’s safe to install. It is certainly not.

1 Like

Restricting binaries to only those built by GH will kill every project I’m involved in.

I use redistributed binaries and libraries in projects that I don’t own the source code, nor is it an open source. None of that code is “built on GH”.

I’d be very careful asking for all binaries and libraries to built with code in the given repository. Many large vendors in this platform publish binaries that the source code is not accessible in GH. That will cause many projects to leave.

1 Like

From the initial conversations that I’ve had with a couple teams (our broader Security and another privacy/trust team) it doesn’t seem like hosting binaries for projects that don’t also host their source code is actually in violation of our ToS.

Though the investigation into this particular one-off is ongoing.


It’s open source, and in the open source world everything has been guided by the “use at your own risk” principle, which includes binaries. Whether Github accepts to be used merely as a binaries mirror or not, that’s a business decision at this point (I mean, it’s their servers and storage, right?).

As others mentioned, enforcing a “Github-built only” approach would be like killing a fly with a bazooka, because a lot of good projects would be removed from Github just to protect a few individuals from accidentally executing a harmful binary.

Perhaps having a “verified” badge in those releases that were built by Github would be enough?
So Github verifying that the binaries were built from a particular version of the code would give consumers of those binaries the certainty that what they’re executing matches what they saw in the repo.

1 Like

That seems even more dangerous to me. Sources might include harmful code (or dangerous mistakes, for that matter), or the build process could load harmful code from elsewhere. If it looks like GitHub is endorsing such builds I fear people might be even less careful about checking what they install or link to.

I’d love to see some sort of badge after actual review, but I kind of doubt that’s feasible at scale.


Well, at that point it would be a matter of how well Github communicates the purpose of those badges to avoid the confusion between “this was built by us just like you’d build it yourself from this codebase” vs. “we guarantee that this software is safe, and recommend its usage”.

Just like the Verified badge in a commit only guarantees the identity of the author, this new badge will only say that the build matches the source code.

An alternative that’s been used for decades is having a checksum. Github could, instead of building and publishing the releases, build the binaries from the source code, compute the checksum and compare that against the uploaded binaries, and put some messages like:

  • The authenticity of this binary could not be verified (if the source code is not available, or there was a build error, or the project is not properly set up)
  • This binary does not match the source code (if the checksum of the internally-built binary does not match the checksum of the uploaded binary)
  • This binary matches the source code (happy path)

At no point Github would be endorsing the usage of the software (as no sane person or company would IMO).

Anyway, just throwing ideas.

1 Like

The checksum is a fickle beast. I struggle to get identical builds from Rust code in different environment. I suspect other languages / compilers would have a similar problem.

I would have a lot more trust in the build if I knew it is guaranteed to be from the source in the repo. Then the onus is on me to verify the code or put the trust in the community as opposed to putting the trust in a single maintainer.

A maintainer may not even have a malicious intent. Maybe some evil hackers compromised his or her laptop and now we are all on the hook.