I have forked a project’s source code on GitHub. The program takes a private key as an input and that key must never leave the client. If I want to share a pre-built executable as a release it is essential that I can prove beyond reasonable doubt that it is built from the published source.
I have learned about how to publish the releases by using a Workflow in the GitHub actions such that GitHub itself will build the project and then repare a release draft with the built files as well as the file hashes…
However, I noticed that the release is first drafted, and at that point I have the option to manually swap the executable and the hashes. As far as I can tell, a user will not be able to tell if I swapped a file and its corresponding hashes. Or, is there a way to tell?
One potential solution that I have found is that I can pipe the output of the hashing both to a file that is stored and also to the publicly visible logs by using “tee”. This will make it such that someone can look through the logs of the build process and confirm that the hashes match the hashes published in the release.
Like this:
I would like to know whether:
-
There is already some built-in method to confirm that a file is the product of a GitHub workflow
-
The Github Action logs can easily be tampered by the repo owner, and the hashes in the logs can be swapped, such that my approach is still not good enough evidence
-
If there is another, perhaps more standard method, to prove that the executable is built from a specific source code.
Well, kind of.
If the printed hash checksum matches with that publish in the release, and it also matches the hash checksum of the release files, then it guarantees that the release files were produced by the github build process. However its very involved to verify that the released hash checksum was the same that was printed by the build process. This probably could be solved by having Github sign all release builds with their own keys. Since signing keypairs usually rarely change, this could be an easier way for verification.
This would verify that the binary was built during the github actions workflow, but only that. Unfortunately, there is much more to it.
First, in the build process, github will use whatever build scripts and instructions the repo maintainer has specified in the github actions files. The purpuse of one of the build scripts may be only to throw away the checked out sources and download a different set from a different place. Or to just add a single more dependency, or just a file, that will compromise the software. However if you have verified yourself that the build scripts only work with reputable sources of dependencies, the repository in question, and other repositories of the maintainer that you have also inspected, then its not really a problem, probably.
But then there is also the question if you trust github (and because of that microsoft, but also the USA because of laws) with always building from the sources, and adding nothing more.
Yesterday I would have said ‘blah, they would not care about my particular small project’. But since then I read the paper recommended by a user in this post about building a compromised compiler that would installs a back-door to a type of login field. I now think it is not so crazy to think that intelligence agencies might collude with Microsoft to insert specific back-doors that somehow allows them to break privacy-related protocols or even recover private keys. Many of these might rely on a specific fundamental principle and so this could be recognized and exploited by a compiler. I came here for a practical answer to a simple practical situation, but I have learned a lot extra 😁
I think there is more to this. Maybe you are targeted because you(r project) reach someone else (the actual target, who you may not even know), but I could also imagine it happening like data mining in the past years: they are not after me or you, they are after everyone and anyone they can reach.