One point to consider is that if you are concerned about this you can audit any changes.
Guy On Thu, 2007-12-20 at 16:49 -0500, Ian Holsman wrote: > 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. > > > -- Guy Ferraiolo mailto:[EMAIL PROTECTED] Performance Measurement & Analysis http://CNET.com CNET tel: 1.908.541.3739 1200 Route 22 East fax: 1.908.575.7474 Bridgewater, NJ 08807 cel: 1.732.618.0250
