Reproducible-builds – Provide a verifiable path from source code to binary
reproducible-builds.org
reproducible-builds.org
In fact, OpenBSD’s and PC-BSD’s package managers do this. It’s briefly touched on in the last slide of this talk: http://www.openbsd.org/papers/eurobsdcon2015-packages.pdf
In other words, even if you are an attacker, you want reproducible builds. :)
Parabola's efforts toward reproducibility have been essentially discarding timestamps by forcing them all to Jan 1, 1990 (a simple date, with a wide gap between it and the Unix epoch) https://projects.parabola.nu/packages/libretools.git/tree/sr...
Perhaps I should add support for this to Parabola's toolchain.
Please do. :) In writing this spec I intended this to be used throughout the entire software community, both closed and open source.
edit: see compiler/compile-time randomization? see some other similar projects under these key terms.
[0]:https://www.ssllabs.com/ssltest/analyze.html?d=reproducible-...
gcc a.c
You would probably need to pass in an "-frandom-seed" option and make sure your environment is the same, but I would imagine you can get that to give you a deterministic output fairly easily.
Most of the difficulty comes in the packaging, where you need to make sure that files enter the archive with the same timestamps/permissions, and in the same order.
I find it really strange that there's a sudden, intense focus on the premise that, given the same source code, when providing it to different people in the wild and asking them to try and compile it, and then having them share their results, doing so reveals variations and disparities that are difficult to explain or account for.
I know why people are suddenly paying attention to this detail: paranoia.
I remember when I noticed this concept had first started to gain some traction. Once people started trying to compile certain open-source crypto applications, and found that their binaries weren't byte-for-byte replicas, it begged the question: Am I actually encrypting my confidential data with a surreptitiously hobbled program? Is there a covert plot to infiltrate and sabotage these sorts of software projects? How would I know if the encryption was weakened in a subtle way, when I don't have the resources to try and crack it at levels that demand well-funded hardware?
But, I wonder, is this something to worry about everywhere?
Is this why so many projects are now taking on this additional activity?
Is there a panic and an anxiety driving this trend, or are we just crossing dotting our i's and our crossing our t's with yet another set of best practices?
Have you managed to dodge all of the above? I haven't. I've had accounts on at least 4 services which were breached at some point. I've seen viruses, adware, and spyware. I've seen script kiddies in my communities, distributing backdoored executables, gathering passwords, and getting banned. And this is only what has failed to escape my notice.
It's not paranoia if they really are out to get you.
> But, I wonder, is this something to worry about everywhere?
Would it be useful for you to be able to detect when your build machine has been compromised, and starts producing malware laden executables? Reproducible builds are a tool that can potentially do that for you - just diff the binaries.
Whether or not it's worthwhile to set up depends on how much of a pain in the ass making reproducible binaries is. Ongoing research into the subject is interesting, if only because it directly correlates to making it less of a pain in the ass when other people figure it out for you.
> Is there a panic and an anxiety driving this trend, or are we just crossing dotting our i's and our crossing our t's with yet another set of best practices?
I wouldn't describe such interest as panic or anxiety - but I wouldn't put it down to merely getting in line with "best practices" either. It's an interesting subject of research - and a potentially useful one at that.