If you use a binary distribution, you're already owned

Forget the days of hunting for exploits and probing for attack vectors.

The big boys have automated software systems for quickly identifying whole classes of exploits in software binaries, and frameworks for automatically generating rootkits using SAT/SMT solvers, concolic testing and attack synthesis. In a matter of minutes, they can have a print out of all of the exploits they can use, and software already to go to own your ass.

How the hell are you supposed to protect against this? Why are so many idiot project maintainers chasing after reproducible builds when this is exactly the type of shit the big boys love? Why aren't the major compiler projects invested in developing SMT-based code generators that can create different permutations of programs from random seeds that can possibly thwart this?

>>27

you still haven't proven that such thing can be used for automatic exploit generation IN PRACTICE. what I would like to see is an algorithm that given current state of quantum computing and OS hardening could automatically go from a simple buffer overflow (preferably on heap as they are more common) in an input function to an equally simple netcat-based shell without crashing target application. bonus points for running in linear or tractable polynomial time. not a program which we wouldn't be able to test anyway but an algorithm that is able to reliably and stealthily fingerprint the machine, find vulns and generates an exploit that bypasses ASLR and makes a ROPchain (keep in mind this might require fingerprinting the application itself given that some programming language/compiler constructs can make exploitation easier or harder - see: overwritable C++ vptrs which makes it easier and stack/heap canaries which make it harder).

more importantly, you haven't proven how not using binary distributions could help you. if something can find vulns in an application compiled by the devs, it will find vulns in an application compiled by tinfoil anon.