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?
There are many barriers to something like this happening.
- For all changes to the source, commit notification emails are
generated, which many developers follow.
- The actual Apache Subversion repository (svn.apache.org) is on a
separate machine with extremely limited access.
- All changes to the stable branch happen on an "RTC" model:
http://www.apache.org/foundation/glossary.html#ReviewThenCommit
- Releases are reviewed in addition to the voting that happened in RTC.
- Personally, I like to run diff -u between two releases.
I believe that the weakest link in most of the httpd release process it
the signed tar balls. If someone subverted a single mirror,
unfortunately, very few users check the signatures, so it might be
awhile before it would be caught. Other open source projects have had
similar issues with mirrors in the past.
The threats you seem to imply is something like an 'evil committer',
which I find doubtful in practice would get anywhere, we have too many
people providing good code review.
-Paul
