Open Source Stack Exchange is a question and answer site for people organizing, marketing or licensing open source development projects. It only takes a minute to sign up.
Sign up to join this community
Other than having someone manually reading all of the code, how can you demonstrate an open-source project's reputability? i.e. it is not a virus/malware/whatever.
I'm not concerned with the efficiency of the program. I just need to be able to demonstrate that the program is exactly what it says it is and is thus not a security risk to install.
The same way as you know any other program is not actually a virus/malware/etc.
You might trust organization x not to publish malware pretending to be something else. You might trust that it's a well known product that wouldn't contain malware. You might perform static analysis.
This is no different than with propriety software.
Not right now, but in the future you'll be able to look for a badge from the just-announced Linux Foundation's Badge Program. The Best Practices Badge is a secure open source development maturity model. Projects having a CII (Core Infrastructure Initiative) Best Practices Badge will showcase the project's commitment to security.
At the moment there's a call for feedback on the criteria for awarding the Best Practices Badge, at Github.
Right now you could use those proposed Best Practices criteria to make your own evaluation of any open-source project.
Also, right now you might look for a digital signature (e.g., file.tar.gz.asc, file.exe.asc) accompanying the distribution, and actually verify it if one is present. That helps ensure that no middleman has tampered with the software before you received it. Even if you don't verify it, you might find the fact that it is present comforting; see this XKCD.com cartoon.
In my experience, this is typically done with various analysis tools.
The first phase is a standard virus check on all of the files to ensure that they are clean. This is true for any software, including open-source as well as commercial packages.
The next step is the use of an approved static analysis tool that includes searching for security vulnerabilities. I'm aware that some projects use HP's Fortify Static Code Analyzer, but others exist as well. Some are even designed to scan binaries. Note that these tools aren't perfect, but they can provide a higher level insight into the quality and any possible issues with an application.
Ultimately, if you're integrating an open source (or any package) into your software application, you should work with the customer to determine what is acceptable. There could be accepted or trusted sources, libraries or packages that have undergone deeper analysis, and so forth. It does depend a lot on who the end user is and what their security requirements are.
I think that your use of the term 'reputability' is important here.
Open Source projects, like commercial products, have reputations. Many organizations make decisions based on reputation. Once in a while, as in Heartbleed, the results are not good.
As others have said, demonstrating that a program 'does what it says it does' is a requirement for a 'provable' program. For a conventional programming language, that's solving the (unsolvable) halting problem. There are some very specialized languages/compilers used for certain critical security and reliability applications that can prove the program's behavior; I've never heard of any open source application written using one; F6 used them.
So, you have to fall back on common sense. What kind of community produces the product? What are their coding standard and review procedures? What do their tests look like? How long have they been around? How widely used are they. In short, well, 'reputation'.
I just need to be able to demonstrate that the program is exactly what it says it is and is thus not a security risk to install.
Almost all open source licenses include language along these lines:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
Basically, with open source software there is typically no guarantee that the program is what it says it is or that it's free from malware.
Trying to claim that your software can be trusted will not get you very far when the license text conflicts with your claim.
Some open source projects will provide the software under two licenses:
The way you guarantee software is good, is my having a person (or company) read the source code and say that the software is good. Involving payment adds extra legal weight on top of whatever credibility this person/company has.
How trustworthy a project is may be reflected in its reputation, but the existing user base simply not care beyond the first question of
Does it even try to do what it says on the tin? Reviews and other evidence of an active user base such as community mailing lists will give you a hand in this area. Some critical thinking about whether you trust the reviews may be required. Inclusion in downstream packages such as a Linux distribution would be a stronger indication in this area.
In case you care more than the current users you could ask a few more questions:
Does the installer/binary only include only what's in the code repository? The most effective way to ensure that nothing unpleasant got injected during packaging is to build from source. If that's too high a hurdle to jump, get the installer from a trusted packager (like you Linux distro) or the project's own site.
Is the code clean/securely built? If you can't or won't review the code base in full you may be able to get a piece of software to do it for you (Fortify, Coverity, ...). This may still not be practical for many people. In which case the next best thing is evidence that the project cares about security. If the project has signed up with the Coverity Scan initiative they have at least looked for issues in the code base, even if the issues have not been addressed. Quick response to security issues raised by community and evidence of code review are also good signs.
F-Droid does exactly that.
The F-Droid team:
If evaluation was successful, your app is then added to the official F-Droid repository with the following metadata:
Only for Android projects unfortunately.
If you want to do this with a static analysis, the answer is that you can't. It is impossible to proof this for code in the general case; if you could, you could solve the Halting Problem - which is mathematically impossible.
A static analysis might find it if there are problems but can never prove that there aren't any.
The best you can do is allow other people to run their virus scanners on it. Basically by opening up the sources you're already allowing them to do just that.
If people are doubtful about your project, they can run it inside a VM and see what happens. Although this is not entirely a guarantee; there is at least one vulnerability VENOM, CVE-2015-3456 that allowed code to escape the VM (privilege escalation).
Technically speaking, to put an attack in a new Open Source project is counterproductive. To pull it off, you would need an attack that isn't in the databases of the malware scanners yet - a zero-day exploit. And by putting it in an Open Source project, you're effectively publishing it. So you might as well publish your zero-day exploit in the reputable way, and make a more positive name for yourself.
