GnuTLS (libgrypt really) and Postfix

[Dave Korn]

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.

  :-) Then what was EINVAL invented for?

> Sure, for many APIs it is posssible to return an error code but this
> requires that the caller properly checks error codes.  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.

  Really it's never ok for anything, not even games, and any program that 
fails to check error return values is simply not properly coded, full stop.

  But abort()-ing in a library is also a big problem, because it takes 
control away from the main executable.  That can be a massive security 
vulnerability on Windows.  If you can get a SYSTEM-level service that 
listens on a well known pipe or LPC port to abort(), you can often steal 
it's pipe or port and escalate your privileges  It would be far preferable 
for the service to remain running in a main loop that ends up operating as 
...

... receive request from client
... fail to service it because libgcrypt returns errors..
.... return error to caller

... rather than for it to abort.

> 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.

  I'm afraid I consider it instead a weakness in your API design that you 
have no way to indicate an error return from a function that may fail.

> It is the same rationale why defining NDEBUG in production code is a
> Bad Thing.

  Perhaps libgcrypt could call abort in debug builds and return error codes 
in production builds?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today.... 




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