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?
-
17Even 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.– Zach LiptonJul 7, 2020 at 1:40
-
10Even if it could be guaranteed to match the code, you still have to trust the repository. See en.wikipedia.org/wiki/Underhanded_C_Contest.– ceejayozJul 7, 2020 at 2:28
-
9@ceejayoz and trust the compiler wiki.c2.com/?TheKenThompsonHack !– Dan M.Jul 7, 2020 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.– user46053Jul 8, 2020 at 19:05
-
1Even 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?– BrandinJul 10, 2020 at 14:30
|
Show 2 more comments
2 Answers
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.
-
31+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, 2020 at 14:23
-
8In fact, I've seen a repo that doesn't have any sources (only a README), and the releases section has the binary-only code.– RuslanJul 6, 2020 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.– MooJul 7, 2020 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, 2020 at 1:49
-
2Anyway 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, 2020 at 1:57
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 checking 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 matches 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.)
-
1"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, 2021 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. Oct 11, 2021 at 8:27