42

When a developer creates a binary from the code and puts it in the releases section, does it match the code in a restrictive way so there is no chance that malicious code is compiled into it? How does GitHub ensure this? Is there a validation mechanism or compiling pipeline applied by GitHub?

5
  • 16
    Even if GitHub applied a compiling pipeline (and they have one, GitHub Actions, which you can use to check out the repository, build it, and save artifacts as releases all within GitHub's infrastructure), you can't meaningfully assure that the binary is what you'd expect because you don't know what all went into it. The build script could install a third-party component which installs another third-party component which downloads something from a random web server which interferes with the build in a malicious way. Jul 7 '20 at 1:40
  • 10
    Even if it could be guaranteed to match the code, you still have to trust the repository. See en.wikipedia.org/wiki/Underhanded_C_Contest.
    – ceejayoz
    Jul 7 '20 at 2:28
  • 9
    @ceejayoz and trust the compiler wiki.c2.com/?TheKenThompsonHack !
    – Dan M.
    Jul 7 '20 at 16:17
  • 1
    @ceejayoz even if the malicious actions were in plain sight in the code with nice comments explaining this is how it downloads additional malware and installs a backdoor, who has time to read every line of code in a really big chunk of code before compiling it. Yeah hopefully that would get noticed quickly in a widely used piece of software, but in some little used piece of software with one maintainer maybe not.
    – user46053
    Jul 8 '20 at 19:05
  • Even if you could guarantee that the releases are, in fact, generated from the sources, does not mean that the program is not malicious. In general there is no way to verify what is malicious or not. A shell script containing a command such as "rm -rf /home" is a trivial example. Is it malicious, or was it actually intended (and desired) to remove all home directories?
    – Brandin
    Jul 10 '20 at 14:30
80

There are no guarantees that the uploaded artefacts match the source code in the repository. That something is on GitHub does not mean that it can be trusted. You need to also trust the maintainers of that repository.

10
  • 29
    +1 from me. Worse, in many cases, you cannot even rebuild the binary from the sources and meaningfully compare your binary with the distributed one; hence. eg. Debian's Reproducible Builds efforts. For an excellent voyage around the appropriate limits for paranoia in this particular direction, read Ken Thompson's seminal paper Reflections on Trusting Trust.
    – MadHatter
    Jul 6 '20 at 14:23
  • 8
    In fact, I've seen a repo that doesn't have any sources (only a README), and the releases section has the binary-only code.
    – Ruslan
    Jul 6 '20 at 20:51
  • 5
    @Ruslan many people use Github Releases and now Github Packages to distribute things held elsewhere - for example, I have many repositories where the only contents is a README and perhaps a Dockerfile, but the Packages feature on that repo is used to distribute a built container image compiled from many sources and different repositories.
    – Moo
    Jul 7 '20 at 0:23
  • 7
    @user17915: I suppose in theory there could be a code hosting service where the downloadable artefacts have to be generated by the service's own CI environment. So, you only have to trust the service that the binaries were generated from the source, you don't have to trust the repo owner. But I'm not sure this would be super-valuable, because (a) under-handed code is not that difficult, especially since most users never read the code, so in practice you'd probably still have to trust the repo owner that the source is good; (b) enforcing the build tools would be a hurdle for users. Jul 7 '20 at 1:49
  • 2
    Anyway reproducible builds are better, in the hope that if the binaries don't match the source for a heavily-used project, "someone" (some kind of a security researcher) will notice and call foul. So, you don't have to trust the hosting service so much. Jul 7 '20 at 1:57
-2

I asked about how the authenticity of releases on GitHub and GitLab can be ensured.

To answer your question: people could sign releases with GPG and publish hashsums of the built release binaries so others can confirm them to be valid or invalid. They could do so by cloning the repository and building the release from the source code themselves and check if the hashsums match.

Relevant to such efforts is the reproducible-builds project. I think packages relevant to the project like compilers should be improved so that such validations are always reliably possible no matter what your build context is, meaning that the builds are deterministic and the binaries perfectly consistent.

Theoretically they'd also need to check if the source code in all the files match what is displayed in the repo because otherwise it could still include backdoors / malware that's not publicly visible on GitHub/GitLab/the public repo website.

If the maintainers don't do so you could even publish the hashsum/s yourself in an issue in the repository asking the maintainers to publish hashsums, it's as easy as running sha512sum ./filename. I don't know why it isn't required or done automatically by GitHb/GitLab or common practice. You only have to also trust maintainers if they only signed their release.

(Hence, I think amon's answer is false.)

2
  • "They can do so by cloning the repository and building the release from the source code themselves and check if the hashsums match." <- have you ever actually tried to do this? I suspect not, because you'll discover reproducible builds (as linked in MadHatter's comment) are much harder than you appear to think. Oct 11 at 0:34
  • Good point, thanks for pointing this out - to make this work it looks like devs would often also need to add info about the build environment. MadHatter said "in many cases". I described how devs could be doing it, not that it currently works. Edited the answer, changing "can do so" to "could do so". Furthermore, as I pointed out in my comments here I think packages relevant to the reproducible builds project should be improved so that it actually works in all cases without any extra info/configurations.
    – mYnDstrEAm
    Oct 11 at 8:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.