Re: How regularly is the GnuPG source code examined?
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


sci.crypt archive

Re: How regularly is the GnuPG source code examined?

From: Alun Jones <alun@texis.invalid>
Date: Tue Sep 27 2005 - 19:16:21 CEST

"Unruh" <unruh-spam@physics.ubc.ca> wrote in message
news:dhbomn$gfr$2@nntp.itservices.ubc.ca...
> daw@taverner.cs.berkeley.edu (David Wagner) writes:
>
>>pv wrote:
>>>Sure GnuPG is open source and regarded as being pretty secure, but how
>>>many
>>>times do people actually examine the source code to it? IF there was a
>>>backdoor in it, how long would it last before someone actually found it?
>
>>I don't know too much about the development methodology of GnuPG
>>in particular, but if they are anything like most other open source
>>(or, for that matter, proprietary) applications:
>
>>Probably a suitably motivated, knowledgeable, clever individual could
>>devise a backdoor that would be very hard to spot. Even (apparently
>>accidental) vulnerabilities have gone undiscovered for quite some time.
>>Probably the main defense is that there is a small core of developers
>>who know and trust each other, and contributions from any other source
>>are likely to be scrutinized by the core developers much more carefully;
>>however, if any of core team went rogue, we might be in trouble.
>
>>This is not a criticism of GnuPG; it's a more fundamental truth about
>>software implementation. It is extremely difficult to build software
>>that is secure when even the developers themselves are malicious.
>
> Yes, but the open source means that the developers know that someone could
> be looking over their shoulders. Closed source is far far more susceptible
> to rogue programmers-- noone to check up.

That's a rather empty argument, IMHO - plenty of closed source programmers
have to worry about people looking over their shoulders at the source code.
There are external audits (particularly of security-related code), formal
and informal peer-reviews, and finally the prospect of having to deal with
requests for help from technical support, if they can't understand the code.

Then there are source licences (a great many governmental organisations and
businesses won't accept programs that they can't peruse the source to, and
they often pay for that privilege).

Open Source's "many eyeballs" doctrine is a tenet of religious faith, rather
than one that's backed up by processes. Open Source is released and
_assumed_ to be looked at by others. How many people in the world could
investigate a crypto implementation and determine if it's secure, safe, or
even correct? Now scratch off all the ones that are too busy working on
other things to engage in code analysis for which they aren't paid. Scratch
off all the ones who can't look at other code because it would lead to
intellectual property issues. Keep scratching, because then you have those
that aren't aware of, or interested in, your work.

Eventually, you're left with a pretty small number of eyeballs, one that can
easily be exceeded by a medium-sized company hiring out for an external
audit. And when you're paid to inspect source code, you're far more
motivated than if you are entirely on your own time, and your only reward is
your own interest in the project you're working on (and possibly a little
advertising). Let's face it, code analysis is dull, dull, dull, especially
if you're trying to do a good thorough job of it. Finding someone to do it
just because it's interesting is a non-starter.

Alun.
~~~~
Received on Thu Sep 29 21:58:20 2005