5 ms·
Its very important in FOSS imo. There is FOSS called ungoogled chromium. And building chromium takes a lot of times (in my case 8 hours). The problem here is c
by cute_boi 5y ago
Its very important in FOSS imo.
There is FOSS called ungoogled chromium. And building chromium takes a lot of times (in my case 8 hours). The problem here is chromium build is not reproducible and repo author can't build chromium for every platform and every versions as its very expensive from him. So what he currently do now is accepts the binaries from others.
But as a user how can I trust the user who build the binaries? He might have tempered with binaries? He might have inserted back doors secretly? Just because he published binaries lets say for 10 years doesn't grants 100% trustworthy right? He might be hacked etc too?
I think reproducible builds fixes such problems. Other than trust factor I really don't think there is significant advantage.
- thakis 5y agoChromium's build is reproducible: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/deterministic_builds.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
- cute_boi 5y agoToo strange. To confirm I went to https://github.com/Eloston/ungoogled-chromium https://github.com/Eloston/ungoogled-chromium it says "NOTE: These binaries are provided by anyone who are willing to build and submit them. Because these binaries are not necessarily reproducible, authenticity cannot be guaranteed;"
- gorgoiler 5y agoI don’t follow your example. Isn’t compile(src, platform) → binary a one way function? If someone kindly hands the repo author a (binary, platform) pair how would the author ever verify the original src value, other than re-doing the 8 hour compile themselves?
- cute_boi 5y agoauthor can't verify , user can't verify that's why we need reproducible builds. if no reproducible builds then, sha256(binary_from_user1) != sha256(binary_from_user2) For smaller project distributing code source is usually correct choice as auditing src code is better than auditing binaries. But the project like chromium I think reproducible build is essential because you can't force everybody to compile and waste hours right?
- rnhmjoj 5y ago> I don’t follow your example. Isn’t compile(src, platform) → binary a one way function? Of course not! It's more like `compile(src, platform, compiler, compiler version, CPU features, current time, current date, your whole file system tree, compiler caches, ...) → binary`. There are also absolute evil build systems that fetch random sources from the internet, then practically the whole world becomes your function closure. Even if you manage to fix or exclude these variables, you could still end up with something that's not reproducible at the bit level: for example, unordered data structures result in binary output that will vary from execution depending on the state of the compiler. > If someone kindly hands the repo author a (binary, platform) pair how would the author ever verify the original src value, other than re-doing the 8 hour compile themselves? If the build is bit-level deterministic it results in a fixed output given a fixed input. So, you simply hash the output, sign it and ship it along the build. The user will simply check if the hash matches the binary they received, even from an untrusted source.
- iso1631 5y agoIsn't that what things like apt do? My Packages file contains the following about a given package that apt will verify SHA256: 04cd079a0676438a8fe1bdf2d897927ead9aa689808f4209d41edadfc3f72f0e SHA1: 2073306c14d4d755d8a32dabce0623e0d9ca3dde MD5sum: f49c2e53ff64d2568f3cb8b6fcb4b112 Release has MD5, SHA1 and SHA256 of the Packages 9ff4da44240de168f7b98d1461d2d96c 65274 main/binary-amd64/Packages dc9007fe54d7f26d0922a377c81e45d9 17568 main/binary-amd64/Packages.gz fd2c8c93e1590e1fc5bc797b20b9ddd670171f1856326a8ba7816f2a6753b779 65274 main/binary-amd64/Packages 06159def8d253ed6f3401cc797bf0f2743b4623a16f996815bf8ffde6f79bfaf 17568 main/binary-amd64/Packages.gz And Release itself has a .gpg signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJhTyrcAAoJECF64EwcjMKfNvUH/RSnkcd41AlOHrrnsDc1P0YL MbV0RrhmHnQYCdO4VvE/C0BTOFstvF0bRDcnCHzEyaU2LvZ7pQFsOTgQqaNjuxSd NyVTIfhwg00AGsEN/MIUZOd2jZLHQQ8esDv0eOCcpO+q4UmBtP6unTCjmdkMekkx SGA/ClfNA1Ql48ZiXMAhn87Vpxvcl4IFtdOV5UZmMVGtMaX1bp7u8Ifz1bm2xbkx .... Of course I still have to trust the person that controls the gpg signing key, but how does that vary with > If the build is bit-level deterministic it results in a fixed output given a fixed input. So, you simply hash the output, sign it and ship it along the build. The user will simply check if the hash matches the binary they received, even from an untrusted source. Or is it that 3/4/10 independent people can independently build the same, concur that the checksums of the built package are all the same, and be confident that none of them are being coerced or hacked? So it's a way of verifying the person building the package in the first place (any coercion/hacking would have to apply to everyone confirming the build - which won't be everyone using it, but would be a dozen people in a dozen jurisdictions
- KMag 5y agoIf the maintainer has 10 people they 99% trust, and they seem unlikely to collaborate, and they all have builds with identical SHA-256 sums, that's much better than picking one build from one of those people.
- matharmin 5y agoYes, it's a one-way function. And if the builds are reproducible, this function is deterministic. The way to verify is to redo the entire compile process. But the advantage is that anyone can do this, so you can have other users in the community validating the builds.
- chupasaurus 5y agoThe media libraries are what is the most of those 8 hours.
- goodpoint 5y ago...which begs the question: shouldn't those be built independently as shared libraries to avoid rebuilding the world?