GnuTLS (libgrypt really) and Postfix

[Ben Laurie]

Werner Koch wrote:
> On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
> 
>>   1) It invoke exit, as you have noticed.  While this only happen
>>      in extreme and fatal situations, and not during runtime,
>>      it is not that serious.  Yet, I agree it is poor design to
>>      do this in a library.
> 
> I disagree strongly here.  Any code which detects an impossible state
> or an error clearly due to a programming error by the caller should
> die as soon as possible.

Quite so.

>  If you try to resolve the problem by working
> around it will increase code complexity and thus error won't be
> detected.  (Some systems might provide a failsafe mechanism at a top
> layer; e.g. by voting between independed developed code).

But this is not why: if you attempt to "fix" impossible states, the
problem is that you cannot know why (by definition) the code is in the
state you are trying to fix, or what else might be broken. Continuing to
run is giving the attacker the option to make good on his exploit.

> Sure, for many APIs it is posssible to return an error code but this
> requires that the caller properly checks error codes.

Again, this it not the issue. If you continue to run code you are
running it against an unknown state of the code and data. You are
allowing more leeway for exploits.

This is true even if the code is "just" printing a warning (don't forget
that to print a warning you must typically execute a substantial body of
library and system code).

>  We have all seen
> too many cases were return values are not checked and the process goes
> ahead assuming that everything went well - this might be okay for games
> but definitely not for cryptographic applications.
> 
> Libgcrypt tries to minimize these coding errors; for example there are
> no error returns for the RNG - if one calls for 16 bytes of random one
> can be sure that the buffer is filled with 16 bytes of random.  Now,
> if the environemnt is not okay and Libgcrypt can't produce that random
> - what shall we do else than abort the process.  This way the errors
> will be detected before major harm might occur.
> 
> It is the same rationale why defining NDEBUG in production code is a
> Bad Thing.

I agree.

Cheers,

Ben.

-- 
http://www.links.org/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com