Topic: [RFC] Trusted build process - page 2. (Read 4265 times)
With modern packaging, checksumming is quite easy -- provided that prelink is disabled (prelink rewrites binaries). So gavin's proposal seems reasonable, and reproducible.
This all sounds good, but for the ultraparanoid, get 2/3/n people to build on a given platform with an agreement on compiler and just compare the checksums, perhaps? Or am I missing a potential attack here?
ribuck: I did misunderstand, sorry.
And maybe I should have been clearer: the idea behind a reproducible virtual image is exactly to capture tools, version numbers, etc etc. Auditors that create their own virtual images with the same CPU, OS, tools, etc. will be relied upon to confirm that yes, the bitcoin executables on the website were indeed built using standard compilers/linkers/etc from a particular source revision.
And maybe I should have been clearer: the idea behind a reproducible virtual image is exactly to capture tools, version numbers, etc etc. Auditors that create their own virtual images with the same CPU, OS, tools, etc. will be relied upon to confirm that yes, the bitcoin executables on the website were indeed built using standard compilers/linkers/etc from a particular source revision.
Gavin, I think you misunderstood what I'm trying to say.
I'm not worried about the developers of gcc. I'm happy to trust them. I'm worried about the person who prepares the virtual image, and who could include their own patched malicious version of gcc.
What I suggest instead is simply to specify the build environment (tools, version numbers and configuration options) and allow others to set up that environment with software from standard repositories.
A virtual image of the build environment is not a big risk, but it seems to me it makes things slightly worse rather than slightly better.
I'm not worried about the developers of gcc. I'm happy to trust them. I'm worried about the person who prepares the virtual image, and who could include their own patched malicious version of gcc.
What I suggest instead is simply to specify the build environment (tools, version numbers and configuration options) and allow others to set up that environment with software from standard repositories.
A virtual image of the build environment is not a big risk, but it seems to me it makes things slightly worse rather than slightly better.
ribuck: what do you suggest instead?
I've read Ken Thompson's paper; that is what motivated me to propose a reproducible virtual machine image as the best we can do IN PRACTICE.
Yes, it is theoretically possible somebody might sneak bitcoin-stealing code into the gcc compiler. Code that detects that bitcoin is being compiled and injects instructions to send coins to the sneaky gcc hacker.
In reality, we trust that the gcc maintainers are trustworthy and careful and that they care about their reputations. If you don't trust them, what is the alternative?
Nefario: can "we" make building bitcoin easier? I've been asking people to submit patches to the bitcoin linux build process, but so far none have been forthcoming...
devrandom: Nice!
I've read Ken Thompson's paper; that is what motivated me to propose a reproducible virtual machine image as the best we can do IN PRACTICE.
Yes, it is theoretically possible somebody might sneak bitcoin-stealing code into the gcc compiler. Code that detects that bitcoin is being compiled and injects instructions to send coins to the sneaky gcc hacker.
In reality, we trust that the gcc maintainers are trustworthy and careful and that they care about their reputations. If you don't trust them, what is the alternative?
Nefario: can "we" make building bitcoin easier? I've been asking people to submit patches to the bitcoin linux build process, but so far none have been forthcoming...
devrandom: Nice!
...that process should be open and verifiably trustworthy ... a pristine, reproducible build environment, preferably as a virtual machine image ...
I think a virtual machine image is a bad idea, because a malicious person could include a modified tool within this virtual image. The C++ compiler, for example, could be modified for malicious purposes, and this might not be detected.
Surely it's safer to specify the build environment (i.e. version numbers and configuration of each tool) and leave others to assemble the build environment from those specifications.
Ken Thompson's very readable 1984 presentation describes this form of attack:
"Reflections on Trusting Trust"
http://cm.bell-labs.com/who/ken/trust.html
This is only a little related to the above thread. Can we make building bitcoin a little easier? After finding the binary doesn't work on my server (amd64 ubuntu 8.10) I went to build and found out about all the libraries it needs (that are not available as apt-get for this distribution).
Probably not too important.
Probably not too important.
I started an initiative ( https://gitian.org/ ) for exactly this purpose. My motivational article is here: http://hyper.to/blog/link/attack-scenarios-software-distribution/
What is needed is a deterministic build process. I would love to collaborate on tools to achieve this.
What is needed is a deterministic build process. I would love to collaborate on tools to achieve this.
Good idea. Besides, I prefer that this image can be mounted, so I can just chroot to it. 
Hello Gavin,
totally agree. There should be a validated process to release new builds without being dependent on a single (or small group of) persons. This is also good for the continuity of the bitcoin project as a whole.
For me personally: The sooner the nolisten=1 config option is compiled into the windows binary the better!
totally agree. There should be a validated process to release new builds without being dependent on a single (or small group of) persons. This is also good for the continuity of the bitcoin project as a whole.
For me personally: The sooner the nolisten=1 config option is compiled into the windows binary the better!
It is time to build and test a new version of bitcoin.
In the past, Satoshi built the Windows and Linux releases, Laszlo built the Mac releases, and we trusted them not to put malware in them (or we compiled ourself from source).
Satoshi is busy, and even if he wasn't he shouldn't be spending his time doing a job that a lot of the rest of us are capable of doing. So we need a new process.
Ideally, that process should be open and verifiably trustworthy. So I'd like to propose that we do the following:
1. For each platform, somebody creates a pristine, reproducible build environment, preferably as a virtual machine image that anybody can download, inspect, clone, run, etc.
Anybody should be able to reproduce the build environment by running or following a script (e.g. "Install Ubuntu X.Y.Z. apt-get the following versions of the following packages... etc").
2. A copy of that virtual machine is used to build/package the release.
3. Anybody can audit the process by re-creating the build environment and ensuring that they end up with "identical" executables. (where "identical" means compare the code in the executables, ignoring timestamps or other meta-info linkers put into executables -- are there already tools to do that, or do we need to roll our own?).
Feedback? Suggestions for improvement, or are there better ways of creating 'trusted builds' ?
In the past, Satoshi built the Windows and Linux releases, Laszlo built the Mac releases, and we trusted them not to put malware in them (or we compiled ourself from source).
Satoshi is busy, and even if he wasn't he shouldn't be spending his time doing a job that a lot of the rest of us are capable of doing. So we need a new process.
Ideally, that process should be open and verifiably trustworthy. So I'd like to propose that we do the following:
1. For each platform, somebody creates a pristine, reproducible build environment, preferably as a virtual machine image that anybody can download, inspect, clone, run, etc.
Anybody should be able to reproduce the build environment by running or following a script (e.g. "Install Ubuntu X.Y.Z. apt-get the following versions of the following packages... etc").
2. A copy of that virtual machine is used to build/package the release.
3. Anybody can audit the process by re-creating the build environment and ensuring that they end up with "identical" executables. (where "identical" means compare the code in the executables, ignoring timestamps or other meta-info linkers put into executables -- are there already tools to do that, or do we need to roll our own?).
Feedback? Suggestions for improvement, or are there better ways of creating 'trusted builds' ?
Jump to: