GnuTLS (libgrypt really) and Postfix

[Florian Weimer]

* Werner Koch:

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

_exit in libraries is fine if you don't service multiple clients from
a single process.  However, with the advent of heavy VMs and stuff
like that, there is a trend towards serving multiple clients from a
single process (which is quite a bad idea in almost all cases, but
this view is rather unpopular).  There are also libraries which
require proper cleanup procedures, otherwise the next program start
can be quite costly (think of databases, where you want to avoid log
replay).  Some services have even been implemented following a
single-process model for more than a decade (IRC servers, for
example).

A user-defined "fatal error" function (which must not return) would be
a compromise, I think.  Of course, such a function should never be
called if you just see wrong or unsual input.  But with a bit of
optimism, the process could recover from an error which is not locally
recoverable (throw an exception, terminate the offending thread, and
leak the allocated resources).

Now if the library maintains global, per-process state, this is a real
problem.  You can't know for sure if this state is consistent after a
fatal error, unless you program carefully to avoid this situation.
Yet another reason to move this functionality to a separate process. 8-)

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