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

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

On Wed, May 06, 2009 at 12:57:06PM +0200, Klaus Klein wrote:
> On Tue, May 05, 2009 at 11:38:36PM +0000, David Holland wrote:
> > On Wed, May 06, 2009 at 12:33:00AM +0100, Alistair Crooks wrote:
> >  > 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.
> > 
> > Having things fail silently or go into a fugue state is not an
> > improvement, particularly in security code. So I'd qualify all this by
> > saying that end-to-end behavior should always be fail-stop.
> > 
> > However, I'm inclined to agree that libraries should not in general
> > abort on behalf of an application, and that it's the application's
> > responsibility to be fail-stop.
> 
> So, as far as the library is concerned, shouldn't these assertions
> be preserved, and face conversion to _DIAGASSERT(3)?

You're right, if you believe that the failure of a runtime check for
the length of time_t being greater than or equal to 4 bytes is
sufficient to abort an application.  There were also assertions about
previous values which had been hardcoded.  Some of the assertions had
code further on to check exactly the same error condition, and return
gracefully with an error value if triggered.

Anyway, on with the meta-discussion.

Regards,
Alistair