A random person on the internet told me that a technology was secure(1), safe to use and didn't contain keyloggers because it is open source. While I can trivially detect the key stroke logger in this open source application, what can developers(2) do to protect themselves against rouge committers to open source projects?

Doing a back of the envelope threat analysis, if I were a rogue developer, I'd fork a branch on git and promote it's download since it would have twitter support (and a secret key stroke logger). If it was an SVN repo, I'd create just create a new project. Even better would be to put the malicious code in the automatic update routines.

(1) I won't mention which because I can only deal with one kind of zealot at a time.

(2) Ordinary users are at the mercy of their virus and malware detection software-- it's absurd to expect grandma to read the source of code of their open source word processor's source code to find the keystroke logger.


4 Answers 4


I recently had the opportunity to perform a software security analysis on FileZilla, eMule, and Shareaza. I ran the code through cppcheck, RATS, and ITS4. No tool will be able to discern whether a piece of code is benign or harmful. It requires visual inspection - which is what I did. I spent two weeks examining line-by-line each piece of source code. I probably missed something. That's why my work was backed up by another person who also found the same or more than I did. For instance, FileZilla utilizes a PHP script to determine your external IP address when in PASV mode. What does that PHP script do? Who really knows? I see your point and point well taken. Depending on your strategy, you should take a risk mitigation strategy and examine the source yourself or hire outside consultants. That way you will ensure that the software is secure. Even if key loggers are potentially installed, however, you still need to practice "defense-in-depth" via firewalls, anti-virus, ACLs, etc.

  • What about eMule? Really keen to know what naughty stuff that's doing.
    – user23157
    Jun 21, 2011 at 18:50
  • @The Mouth of a Cow: Calls to some outside php scripts such as in Emule.h on Line 27 : "porttest.emule-project.net/connectiontest.php". Calls to an outside version upgrade tool in WebServer.cpp. Bunch of programming errors, potential buffer overflows, LoadLibrary vulnerabilities, ShellExecute vulnerabilities, etc. Jun 21, 2011 at 18:59
  • Do you electron microscope the chips in your made-in-china keyboard? Should you if you are a defence contractor? Jun 21, 2011 at 21:05
  • @Martin: Depends on how secure you want to be I suppose. Jun 21, 2011 at 21:08
  • @MartinBeckett Admittedly, unless the driver co-operated, sucha chip wouldn't accomplish much. I suppose it could try to connect to unsecured WiFi, but I feel like that would be bound to be noticed eventually. Jun 25, 2016 at 3:23

This falls into the "trust it, its open source" category. If enough people are looking at the code of a project, it is unlikely anyone can slip anything nefarious by. Also, look at the reputation of the party that is backing the project. Is it J. Random Coder, or Apache Software Foundation? Obviously the smaller the codebase the harder it is to slip anything in. And does the open source project depend on any external libraries that are not open source? If a project is a custom branch of an obscure project hosted on a unknown website... well.

Also, I would not worry specifically about keyloggers, but more security in general. This includes accidental security breaches, which are far more likely to occur in a small project. Backdoors, poorly implemented privacy, and needed access to the system are all risks that are more likely than an intentional keylogger.


Developers can prevent rogue committers to their open source projects by not giving everybody and their penguin commit privileges. The distinguishing principle of Free Software/Open Source is not that development is crowd-sourced (although it can be) but that it's possible to fork projects.

People downloading software need to execute a little care, and that's just as true for F/OSS as for proprietary/closed source software. Software you get from a reputable source is usually good (in either case); software from a fly-by-night is more likely to have malware.


It's not like anyone has commit access to any open source project. And even if someone commits malicious code, it can be discovered since the source is public. If you don't trust the managers of the project, you can always hire someone like 0A0D to inspect the code for you. It's not perfect, but it's better than the alternative;

For a closed-source project, you just have to trust the supplier. How do you know that there are no backdoors in closed-source software? You don't. Malicious code can have been added by a disgruntled employee, someone looking for a way to make some cash, an evil janitor that happened to have access to the company's repository... In closed-source software, there is no way of knowing.

  • I had in mind open source as in source forge and github, not open source as is published. If there is a vendor, you have some assurance than the code isn't malicious because you can take a known supplier to court and get civil damages and criminal punishments. An open source project is a bunch of more or less anonymous contributors that you can't take to court, or if you did, they won't have much to lose for it. Anyhow, if disgrunted and evil doers are everywhere, then closed and open source 3rd party code is equally dangerous to use. Jun 21, 2011 at 21:07
  • Open source is a trademark, so when I say open source I mean it by the OSI's definition.But there is a vendor, even for open source software. I don't know if a vendor can claim no responsibilities to code that is obviously malicious, but most open source projects try as the license often contains a "no warranties" clause. Jun 21, 2011 at 21:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.