Take the 2-minute tour ×

I'm about to download some OSS software, and I would like to ensure (with a reasonable degree of certainty) that it hasn't been tampered with to insert malware. Specifically, it's a password manager (KeePassX), which seems like an extremely juicy target for hacking, so I'm feeling particularly paranoid.

The two vectors for malware insertion that I can think of are:

  • Malware making its way into the official source code.
  • A malicious fork or build being substituted for the official one on the website.

The download page does provide checksums; however, this wouldn't seem to protect against the above two hacks.

I don't have the expertise or time to do a source code audit.

What are best practices for checking open source software of a sensitive nature for malware?

share|improve this question
The devs need to digitally sign what they provide with their well known keys. GnuPG has verification functionality integrated, you can verify integrity of new version downloads using the currently installed version (which you already trust). –  Daniel Beck Sep 27 '11 at 14:06
I wouldn't be too concerned with potentially tampered with source code. What should be of slightly more concern is whether there is a potentially compromisable section of the code that could be externally tampered with. –  Enigma Mar 7 '13 at 16:34

4 Answers 4

up vote 3 down vote accepted

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.

share|improve this answer
So how'd you explain CVE-2008-0166 if the likelyhood is nil? –  Daniel Beck Sep 27 '11 at 14:48
@Daniel: It's neither intentionally malicious, nor malware. The bug was introduced by Debian package maintainers' patches. –  grawity Sep 27 '11 at 15:18
@grawity He argues that eyeballs solve every problem introduced by malicious committers. In this case it was an accidental commit, but I doubt attackers provide /* compromise security */ comments with their code. Attacks won't look any more conspicuous than this. –  Daniel Beck Sep 27 '11 at 17:09
The answer, as ever, is in the evidence. Linux, as a forefront OSS project, would be a particular target of malicious code injection (much like Windows is the biggest and most popular malware target), but it simply hasn't had any significant issue with this. Not being involved in the community, I can't say why this is for certain. I'd imagine, though, that the community has found a way to verify and trust, even in a dispersed, decentralized way. The evidence proves my argument. –  music2myear Mar 8 '13 at 16:15

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.

share|improve this answer

If you find a mirror of the packages, you can compare with their checksums.

This would protect against the second vector, provided that the packages were mirrored before they were substituted.

For protecting against the first vector you'll likely have to look at the changes in the source code.

share|improve this answer
Similarly, I could also check whether an older snapshot of the download page posted the same checksums. –  Reid Sep 29 '11 at 2:03

Malware making its way into the official source code.

Unless you are dealing with daily builds this unlikely to happen.


This would require access to the website, which is unlikely to happen without being noticed by somebody, you should be far more worried about MySQL's website being compromised.


Sure it does... Somebody had to post those values they were not generated automatically.

share|improve this answer
Re. your last point: I'm assuming that someone with access to post a malicious build would also have access to the website to post new checksums. –  Reid Sep 29 '11 at 2:04

Your Answer


