Re: CVS commit: src/crypto/external/bsd/netpgp/dist

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Tue, May 05, 2009 at 11:52:09AM -0400, Perry E. Metzger wrote:
> 
> "Alistair G. Crooks" <agc%netbsd.org@localhost> writes:
> > + get rid of some assertions in the code - this is a library - about 100 to 
> > go
> 
> Why does the fact that it is a library make assertions a bad thing,
> especially in security code?

It doesn't per se - but I personally have an aversion to libraries
that dump core in the middle of running well, especially when calling
code checks for bad return values and deals with them just fine.  I
was going to say that the fact that this is security code is neither
here nor there, but that's not exactly true.  I'd really prefer it if
a data section which could contain my PGP passphrase did not get sent
to a disk somewhere.

To illustrate this - I messed up one of the assertions when I was
converting it to an if() test, such that the condition was inverted. 
The regression test showed this up straight away, and presented me
with a "bad length" message along with the function name where it
happened.  Personally, I find that much more socially acceptable than
dumping core on me.

Imagine someone embedding this library in their (embedded) product.
Having the library dump core for what is an unusual ocurrence, admittedly
(such as an out of memory condition, perhaps) is suboptimal, since the
product may then have to be re-started to get a working system. This
is too intrusive. As someone with an LCD TV which sometimes does this,
it annoys me intensely. Names and models on request, in private.

This also brings us round to a pet peeve of mine - for development
work, dumping core is fine for exceptional conditions. Same as kernel
panics. It's not usually wanted in production code.

We have too many of these core dumps and panics - we should only take
drastic action when the system as a whole cannot easily recover.  For
me, these assertions in netpgp are recoverable - return a false or
"error condition" value, and try to continue.

Regards,
Alistair