GnuTLS (libgrypt really) and Postfix

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