this post was submitted on 13 Aug 2023
72 points (96.2% liked)

Open Source

31654 readers
130 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] noneabove1182 0 points 1 year ago (1 children)

Besides the obvious of telling your users to build the exe, have you considered alternative distribution methods like docker?

[–] [email protected] 2 points 1 year ago (1 children)

How does a docker distribution solve this problem? Is it because the build instructions are automated by the Dockerfile?

[–] noneabove1182 2 points 1 year ago (1 children)

When you make a docker image and push it to dockerhub all of the instructions it took appear there so it's very transparent, also super easy for any person to build it themselves unlike executables, just download the Dockerfile and run a single command

[–] [email protected] 2 points 1 year ago (1 children)

Ah. Cool. I was under the impression that docker images suffered from a similar issue - that one can't verify that the image is built from the source. I'm happy to be mistaken about that.

[–] noneabove1182 2 points 1 year ago

You could definitely do clever things to obfuscate what you're doing, but it's much easier to replicate building the image as there are no external dependencies, if you have docker installed then you can build any docker image