171–178 of 178 posts
Earlier quoted context omitted.
Bit for bit matching is not required for that.
It makes it much simpler and more robust though. Also, it allows for content addressing a la Nix, among other benefits.
You can content addressing without reproducible builds. You just have a canonical version, which typically is built by the application developer.
Earlier quoted context omitted.
Anyone can verify the actual code in the binary matches even if some bytes within the binary file itself are different. The verification routine doesn't have to be a basic bit for bit equality test.
For sure. This has been the status quo in Debian for a while now. You can build, and use diffoscope to audit the differences. It's a stronger security property to have bit-for-bit reproducibilty, and it looks like Debian are ready to commit to it.
Earlier quoted context omitted.
For sure. This has been the status quo in Debian for a while now. You can build, and use diffoscope to audit the differences. It's a stronger security property to have bit-for-bit reproducibilty, and it looks like Debian are ready to commit to it.
You are just restating the point of the thread and not addressing the low return on investment doing this is.
I had figured the cost would decrease in time as deterministic builds became the norm (i.e. build tools stop including build timestamps).
I agree that it might not have positive POI. Bit tricky for me to judge.
Earlier quoted context omitted.
Sure. The site appears to be a bunch of warm-fuzzies that could apply to almost any other measure you take, it's nothing specific to reproducible builds. As the original poster said "There was no bug or attack on Debian since 2007 that reproducible packages would prevent". In fact, it could be argued that reproducible builds lead to a reduction in security, not an improvement: They give an attacker an exact fixed mem…
This comment is misinformed. Non-deterministic builds would also result in one tarball redistributed to all distro users. The ROP exploits don't work because of ASLR.
Most with failed to reproduce: NT_GNU_BUILD_ID. The others on some other bits. Mostly timestamps or hashes I assume
Earlier quoted context omitted.
newcomers will always have it much easier. also guix i think also reached this. also, stagex and others probably profited QUITE A LOT from the debian efforts, because they started to go upstream and talking to developers.. just arch linux profited from debian maintainers a decade before that an debian people asking upstream to improve...
Guix did a full source bootstrap first, credit where well due, but it does not apply to their whole tree. E.g haskell is bootstrapped with a binary, qemu includes binary firmware blobs, etc. Guix is not fully bootstrapped or reproducible. To your point though, the incomplete efforts of many other distros absolutely accelerated us.
Yay for Free software and Opensource! we all benefit! :)
Earlier quoted context omitted.
You could already do that since Debian cryptographically signs all its package indexes, and the indexes contain the hash of all packages. The additional guarantee that reproducible builds bring is that you can re-build the packages in your own controlled environment and verify that the resulting package is bit-for-bit identical to what Debian offers.
Cryptographic signatures only protect against MitM (something extremely rare in the real world) and do nothing against compromised Debian infrastructure and supply chains (the real attack vector 99% of the time). Reproducible builds protect against all attacks.
Generic statements like this are always false. As a simple rebuttal, reproducible builds do not protect against source-level attacks such as intentional backdoors or disabled/obfuscated access checks. In fact, I'd say that reproducible builds protect against one class of attacks only: compromise of the build infrastructure.
Earlier quoted context omitted.
This comment is misinformed. Non-deterministic builds would also result in one tarball redistributed to all distro users. The ROP exploits don't work because of ASLR.
ASLR makes ROP attacks harder, it doesn't stop them, as a great many successful attacks have demonstrated. Heck, bypassing ASLR is taught to students at MIT... can't find the direct link ATM but here's a student assignment, https://csg.csail.mit.edu/6.S983/labs/aslr/ .