While open source is fantastic, and provides highly visible means.
It can still be hacked.

I can describe what has happened in this case:

1. joe hacker hacks one of the 'open source groups' machines.

at this point he is assumed to have access to the source code repository.

2. assume he figures out how to change the source code in the repository in some weird way, or then modifies the tarball.


a. he modifies the tarball and inserts some trojan.

at this point in time people will be downloading the trojan, and it will start infecting people who are lazy. The non-lazy people (and there are people out there who do this) will check the MD5 & GPG-Key of the tarball, and will verify that the code matches the signatures. when it doesn't they complain VERY LOUDLY. They even complain when the GPG key is not signed with enough people who have enough trust.

so as long as you and your employer always verify with the GPG-key of the tarball that it is signed correctly, then this is not such a big issue.

b. he modifies the source code in the repository directly and in a manner that doesn't generate an email/commit message.

when something like this occurs ( I'm not even sure if it is possible in SVN, but I think it was in CVS) then the next time one of the core developers update their version of the code they will see the code has been changed. It is then up to the developer to review the change or the file being changed and to see what has happened. Our developers are alert, and most will question what is going on... but it is a risk.

regards
Ian

Jim Jagielski wrote:

On Dec 17, 2007, at 6:22 PM, Andrew Beverley wrote:

Hi,

I hope that this is the correct mailing list for this question, and that you can
easily provide a quick response.

I am currently working within the UK Ministry of Defence, and am trying to get Apache web server accredited as software able to be installed on one of our defence networks. However, one of the barriers I am coming up against is the argument that, because it is open source, that someone could contribute a Trojan horse to the code and that the code could be included in the official product.

What I would like to know, so that I can dispel this, is what procedures are in place to prevent this happening? I know that all downloads are digitally signed, but what other procedures are in place? For example, how is code signed-off for
inclusion in production releases?

I am going to a meeting about this very shortly so would appreciate a prompt
response!


In one word "visibility".

Since all development is done in the open, and since all code
is vetted by at least 3 committers on the project and all commits
are viewable via subversion, the risk associated with this
is pretty pretty small.


Reply via email to