76
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 Aug 2023
76 points (96.3% liked)
Open Source
31060 readers
351 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
I don't know whether github actions output can be tampered with by you, but the only actually reliable way (that I know of) to prove that your binaries correspond to a certain state of the sourcecode is to support reproducible builds (See e.g. https://reproducible-builds.org/).
All other methods require trust (in either the developer or w.r.t. github actions towards github).
The drawback is of course, that to verify whether your binaries are good, someone needs to rebuild the software, but it is a good tool to build and maintain trust in your signed binaries, especially if they deal with sensitive information like private keys.
An important point to add for someone who hasn't heard of reproducible builds before: The key difference to a normal build process is that it is 100% deterministic i.e. it produces exactly the same output every time.
You might think that most built processes would be like this by default, however this is not the case. Compilers and linkers usually have some non-deterministic values that they put in the final binary such as timestamps. For a build to be deterministic these sources of variation must be disabled or mocked to be a repeatable value (i.e. not based on the actual compile time).
True, while I think the page that I linked explains the concept well, it might not be easy to digest for someone who is new to software development.
But then again, if you handle cryptographic materiel, you better learn fast 😃
Yeah that site is pretty good. There's a lot of information though. I think a good starting point is maybe this page: https://reproducible-builds.org/docs/env-variations/
Yeah, this topic would actually lend itself to an intro video which demonstrates the problem on a tiny project.
Unfortunately given how hard reproducible builds are they aren't done much, and aren't talked about much. A vicious cycle. A nice short video would indeed be helpful for understand and awareness.
Hopefully some day I will be able to create reproducible builds independently of github. But I am thinking that their workflows are reproducible builds, correct? So, anyone should be able to fork the project and run the workflow and it will build the program in the same way. I am O.K with the user needing to trust GitHub on this - it really is me who I worry about. I don't want to tell someone that they have to trust me. I want to be able to remove blind trust from my own personal contribution. The program itself is built on top of many dependencies, so the user is also implicitly trusting a large amount of maintainers.
In my specific scenario I'm forking a community project (a crypto wallet) that the maintainers no longer want to maintain nor share PR access to. I'm adding a patch to fix some broken hard-coded endpoints. So what I want to be able to do is to transparently say "Here is my very simple commit that you can read, and here is the executable in case you want to download the fixed wallet but are not technically savvy enough to build it". I don't have any reputation in this community, nor do I share my identity. I would prefer to be able to remove the element of trust. Asking trusted members of the community to build from source and verify the checksums would be nice, but I don't think it is such a simple thing to ask in this case.
(My instance won't fetch content from lemmy.world, I'm not sure why... That's why I switched to this account)
A reproducible build is more than an automated build. It is a build process which enables any third party to build a binary that is bit-by-bit identical (see https://reproducible-builds.org/docs/definition/).
So if I would build a specific release/commit of your application on my PC (given an identical development environment, i.e. same version dependencies, compiler, etc.) it MUST result in a bit-by-bit identical binary to the one you built on your development machine and the one the github workflows built.
All these binaries would result in the same hash (and thus be verifiable by the same signature files).
Other than a signed binary from a trusted developer/organization, there is (IMHO) no way for a non-tech savvy user to gauge the trustworthiness of a binary they download from the internet, and even then a signing key might have been lost or broken (see the recent Microsoft debacle w.r.t. AD signing key misuse).
Thanks a lot. I have been evangelized by you and the other commenters. I see now that reproducible builds is the solution.
I now understand better the value of reproducible builds, and the more I think about it the more I realize that it is very bad that something as sensitive as a crypto wallet executable that does not follow the reproducible build standard has been going around. I do trust that the devs are not being malicious, but it is essential to have a good way to verify. Even the original github workflow is failing to build now, and new flags need to be passed to npm while building due to some openssl changes, so I'm not sure that anyone can actually reproduce the build today and get the same hash.
I'll read more about how to do it properly, and I'll try to create a Reproducible Build fork if I can actually pull it off.