Are You Sure This Is the Source Code? 311
oever writes "Software freedom is an interesting concept, but being able to study the source code is useless unless you are certain that the binary you are running corresponds to the alleged source code. It should be possible to recreate the exact binary from the source code. A simple analysis shows that this is very hard in practice, severely limiting the whole point of running free software."
Re:Bogus argument (Score:5, Informative)
The guy who submitted that article is the person who wrote it. Awesome "work", editors.
Some things wrong with TFA (Score:4, Informative)
Re:Bogus argument (Score:5, Informative)
To borrow from The Watchmen:
Who compiles the compiler?
Your attribution isn't just a little off, it's way off.
Try Iuvenalis, around 200 AD.
Re:touch o' hyperbole (Score:1, Informative)
This would be true if an executable binary was some kind of quantum black box, like the inside of a proton or whatever. In actual fact, a binary is a set of disassemble machine code and you can compare the differences between the version you compiled to the published version as you would like. The article writer found that usually the "difference" was a build timestamp, because duh.
Re:Bogus argument (Score:5, Informative)
There are very talented people that can hide things in only a few lines of code. See http://ioccc.org/ [ioccc.org] for some examples that will make your skin crawl.
Re:Bogus argument (Score:5, Informative)
Who compiles the compiler?
I guess it's time to introduce another generation to the devious genius of Ken Thompson [bell-labs.com].
You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)
Re:Bogus argument (Score:5, Informative)
Yeah. Unfortunately, the issues he presents here DO make it more difficult to prove that someone is providing a binary that could NOT have possibly originated from the provided source code.
As an example, the kernel source initially released for the Samsung GT-N8013 (USA Wifi Note 10.1) was not what was used to build the binaries in question.
The "difficult to prove but obvious" - Any kernel built from the provided source had a massively broken wifi driver that would completely stop functioning, usually within 5-10 minutes, requiring the module to be removed and reinserted. Pulling the wifi module source from a different Samsung tarball (such as a GT-I9300 release) would result in a working driver. But how do you prove the source provided is correct?
In the case of the N8013, we were lucky - Samsung changed a bunch of debug printk()s slightly in their released binary. Small stuff, not functionally relevant, such as typo fixes and capitalization differences in their touchscreen driver's debug printk()s - but at least provable to be different.
So we could prove that the kernels didn't match, but couldn't necessarily prove that the biggest functional problem was due to a source difference.
We asked Samsung to provide source that corresponded to the UEALGB build for that device, and their response was, "That build is a leak and hence we are not obligated to provide source for it." Effectively admitting that the provided source was not meeting the requirements imposed by the GPL for that build, and then claiming that the software build preinstalled on every device sold in the USA for the first 1-2 months after launch was a "leak" and thus they didn't have to provide source for it.
Needless to say, between that and other situations, that was my last Samsung device.
Re:Bogus argument (Score:5, Informative)
But unless and until he reads AND UNDERSTANDS every line of the source he is
always going to have to be trusting somebody somewhere.
Even if he reads and undertands every line of the source, he's still trusting someone. He has to read and understand every line of the source code of the complier he is using, and the compiler that compiled that compiler, and so on.
Reflections on trusting trust [bell-labs.com] is almost 30 years old now. It should be well known.
Re:Bogus argument (Score:5, Informative)
For true malice there's also The Underhanded C Contest [xcott.com].
From their home page: "The goal of the contest is to write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil."
Re:Bogus argument (Score:5, Informative)
"Exact binaries" is not the point of having the source code.
Uh, you must not have worked in a shop that does continuous integration automated builds? Do you really think QA should be handed binaries that you compile and have them trust them?
The problem is that GCC will always give you a different binary every time you compile from the same source. This makes it impossible that the binary you received comes from the source you claim to have used. You can get around this by never receiving binaries from anywhere but the automated build machine but it would still be useful to be able to test that a build that you received was built from the code you expect.
There were several reasons why Apple moved away from the GCC tool chain to LLVM and Clang but one of the abilities of the LLVM stack is that you can actually get identical binaries from the same source compiled on different machines at different times.
Bad choice of target (Score:5, Informative)
Bad choice of target - .Net does actually have multiple compilers available, including open source. But more to the point for this discussion, it has multiple DEcompilers available, including open source.
Want to know what that nasty MS compiler put in your .Net binary ? - run it through ILSpy.
Don't trust the ILSpy binary - decompile it with itself, or with a.n.other decompiler.
In fact, because .Net decompiles so well, the problem of this article (binaries don't compare) just doesn't occur. Want to check your .Net binary against the supposed source ? - easy (well, a hell of a lot easier than with C++). Build your binary from the source, decompile both binaries and compare the two sets of decompiled source. It works, it is consistent and reliable, and it is one hell of a lot more useful at showing up differences than comparing two binaries.
Re:Bogus argument (Score:5, Informative)
The latest alpha release [torproject.org] of the Tor Browser [torproject.org] uses a deterministic build process for exactly that reason: users of open source software (or the small minority of users with the necessary technical skills) should be able to check that the published binaries match the published source exactly - no malware, no easter eggs, no backdoors. If someone detects a mismatch, they can alert the rest of the community.
Mike Perry, who spent six weeks getting deterministic builds working for Tor, has some interesting thoughts [stanford.edu] on why this is an important issue for security tools, even if the users completely trust the developers.
I'd like to see more open source projects following Tor's lead. Gitian [gitian.org] is a deterministic build tool that might help - it enables multiple people to build a binary from the same source and check that they get identical results.
Re:Bogus argument (Score:3, Informative)
I used to work on GCC, and the randomness you describe would have made it impossible to find bugs.
GCC is deterministic. If you feed it the same input and launch it with the same options, it generates the same output. GCC developers would never tolerate random behavior.
Is it possible that you have address randomization turned on in your OS? I used to to use watchpoints & similar in the heap, and this would only work if randomization (ASLR/PAX) is disabled.