GnuTLS (libgrypt really) and Postfix

[Victor Duchovni]

On Sun, Feb 12, 2006 at 04:45:33PM +0000, Ben Laurie wrote:

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

No, libraries don't enough to decide what's fatal. The calling
process (trying to an LDAP lookup via nsswitch.conf say...) may have
other reasonable sources of data, and having the library kill it is
unacceptable.

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

Not being able to access a resource is not an "impossible"
state. Impossible states are corruption of internal data structures,
invalid function arguments, ... Failure to obtain seed data is an
error and needs to be reported as such.

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

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