4 ms·

> 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, compil

> 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 ago
Isn'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
- rnhmjoj 5y ago
  > My Packages file contains the following about a given package that apt will verify Those hashes and signature confirm that the package is coming from a maintainer, but it can't confirm nor deny that the package you received was actually built from the sources the maintainer claims to have used. Simply because there's no guaranteed bit-level link between sources and output. > 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? Yes, the improvement compared to traditional packages is that given the package inputs (sources, dependencies, build instructions) and the output you can be sure that the output is the result of building the inputs. You don't actually need multiple indepdent people: just rebuild the package and compare the hashes. Again, you could try to do this with APT and it will probably work for some very simple software (or some that the Debian maintainers managed to make reproducible), but not in general.

iso1631 5y ago

Isn'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

rnhmjoj 5y ago
> My Packages file contains the following about a given package that apt will verify Those hashes and signature confirm that the package is coming from a maintainer, but it can't confirm nor deny that the package you received was actually built from the sources the maintainer claims to have used. Simply because there's no guaranteed bit-level link between sources and output. > 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? Yes, the improvement compared to traditional packages is that given the package inputs (sources, dependencies, build instructions) and the output you can be sure that the output is the result of building the inputs. You don't actually need multiple indepdent people: just rebuild the package and compare the hashes. Again, you could try to do this with APT and it will probably work for some very simple software (or some that the Debian maintainers managed to make reproducible), but not in general.