Verifying that open source software hasn't been tampered with
Solution 1:
If you fear the source, which is what your question implies, there is no way you will trust the software.
The solution is to stop fearing the source.
To do this you can focus on the fact that out of the thousands, probably millions, of OSS software projects, the number of projects that have been infected and that infected code approved and merged into the main codebase is nil.
You can also focus on the logic of the issue: Due to the large number of eyes going over each piece of the code, and the extremely low odds that a sufficient number of those eyes are bought off by the malware makers to force the nefarious code to be included, the likelihood that bad code has made it into a tool such as that is also nil.
For these reasons I try to stick to reputable, well recommended, well supported, and actively developed OSS tools for critical software. In all these situations we're playing with odds. And while the default odds are extremely low, the odds of an active software project being infected are even lower than the default.
Solution 2:
How paranoid do you want to be? Do you trust your compiler? There is an interesting story (read the section Reflections on Trusting Trust), from Ken Thompson, one of the original creators of Unix. It describes a system where the login program has a backdoor allowing him to access any machine. The compiler is modified, so that when someone compiles the clean source of the login program, the compiler notices and inserts the backdoor code.
The compiler also notices if someone is compiling the clean source of the compiler, and inserts the proper code there as well. In those days, everything was available as source, but you would need a binary version of the compiler as a place to start. So the malicious code never shows up in the source code, but propagates itself as bits of the system are recompiled. This would be incredibly difficult to figure out, basically requiring auditing the running code.
Back to the original question, you have to trust someone. The question is how far up the chain do you need to go? With a well known project, odds are someone will notice if there is a problem pretty quickly.