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 - 20:49:37 CEST

"David Wagner" <daw@taverner.cs.berkeley.edu> wrote in message
news:dhbu9t$v8k$3@agate.berkeley.edu...
> I don't think this helps: I'm pretty sure a core developer could still
> sneak in an undetected backdoor, if they were sufficiently motivated.
>
> Do you remember some of the prior PGP bugs, like the one where the
> randomness
> source wasn't read because a return value wasn't checked? Stuff like that
> could slip past a code review, whether or not you have comments and coding
> conventions.

Good tools help that, though. Marking return values as "must be checked",
and then checking that all "must be checked" return values _are_ checked is
a must-have on a source analysis tool.

Clear commenting and structure, while they are a hindrance to sheer speed of
development, greatly aid in reading the code and deciphering its function.
Obviously, the code is the code, and the comments aren't, so you'll
occasionally get something like:

/* Add 5 to x */
x*=5;

OR

/* if x is greater than 5, print the following two lines */
if (x>5)
    printf("First line\n");
    printf("Second line\n");

But that kind of thing is not what clear commenting is designed to stop.
Clear commenting is an inline documentation of the purpose of the function,
and should not be treated as a substitute for reading the code!

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