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.
As far as I’m aware, there is no way to fully know there wasn’t any tampering or swapping of executables that were produced by a workflow. As most things on the internet, I believe there needs to be a degree of trust towards the original author and original owner of the repository that what they published is indeed a built executable from the original source. If there is any doubt about this, the only verifiable way to know for sure, if for a potential user to build from source themselves.
I can think of ways where there is a trusted third party that provides a public key with which to sign the built executable, after which it can be checked by the third party (with its private key) whether it is still the same executable. Specially if a different key pair is used for every signing operation. But there are still flaws there, and would, ultimately, still rely on a degree of trust in the third party.
Let’s say that I do trust GitHub as the third party. Is it possible to ask GitHub itself to sign the executable with a specific key created for a given workflow, and that only GitHub owns? Maybe it already signs it. I’ll look into it.
(My instance won’t fetch content from lemmy.world, I’m not sure why… That’s why I switched to this account)
Github doesn’t do any signing at all nor do they rally care about the actual output of actions, pipelines or manual releases (all of that is out of their interest scope).
If there’s any means of a ‘secret store’ for the build actions then you could store a keypair for signing the binaries as far as your target binary format and platforms support it (or go for something like a detached gpg-signature that can be stored with the build or in a central ‘trusted’ repository so the binary can be verified against it later).
You users however would still have no easy means to verify that signature on most platforms unless they are tech-savvy. (macOS code signing / notarization and gatekeeper check would be an example of a platform that would notify users and even fail to run the binary if it was tampered with).