GnuTLS (libgrypt really) and Postfix

[John Denker]

James A. Donald wrote:

> The correct mechanism is exception handling.

Yes, I reckon there is a pretty wide consensus that exceptions
provide a satisfactory solution to the sort of problems being
discussed in this thread.

> If caller has provided a mechanism to handle the failure, that
> mechanism should catch the library generated exception.  If the caller
> has provided no such mechanism, his program should terminate
> ungracefully.

OK ... although I wouldn't make a virtue of doing things ungracefully.

> Unfortunately, there is no very portable support for exception
> handling in C.   There is however support in C++, Corn, D, Delphi,
> Objective-C, Java, Eiffel, Ocaml, Python, Common Lisp, SML, PHP and
> all .NET CLS-compliant languages.

That raises the question of whether mission-critical applications
should be written in C.

It is straightforward but laborious to simulate exception-throwing
in C:
     extern int errno;
     /* try some stuff */
     if (errno) return;         /* return immediately on any error */
     /* try some more stuff */
     if (errno) return;         /* return immediately on any error */
     et cetera.........
This is laborious and inelegant, but no more so than the other gajillion
things you need to do to provide any semblance of security in C, such as
computing the (N) argument to strncat(,,N).

In particular, if-errno-return is often much preferable to some other
tricks that have recently been suggested, such as raising SIGABRT or
passing a pointer to a function to be called when exceptional conditions
are detected.  The reason is that throwing an exception _pops_ the
stack until a catcher if found, whereas signals and function-calls just
push deeper into the stack ... they allow you to regain some control,
but they don't make it easy to regain control _at the right place_.

For completeness, let me say again that _exit() is just an exception
that is caught by the parent process.  If you are ever forced to deal
with a package that exits when it shouldn't, it is straightforward to
create a wrapper that does a fork, calls the package, and collects
the exit status.  That is, rather than:
         rslt = nasty(a, b);           /* might trash the whole process */
we have:
         rslt = forku(nasty, a, b);    /* better */
         if (errno) return;
But of course I hope you never have to face such a problem.  If at
all possible, use a language that supports exceptions.

> Absent exception handling, mission critical tasks should have no
> exceptions, which is best accomplished by the die-on-error standard.

No, that is not the "best" way nor even a good way, let alone a standard.

> Halt on error is a tool for achieving error free code.  Error free
> code is in fact achievable for really crucial applications.  The more
> crucial the application, the more reason to write code that halts on
> error. 

Halting on every exceptional condition is like amputating to cure
every headache.

Keep in mind Dykstra's dictum:  testing can perhaps show the presence
of bugs, but testing can never show the absence of bugs.

Exit-on-error is a _problem amplifier_.   It guarantees that small
problems detected during testing will not go unnoticed.  But this is
a very long way from being a guarantee of error-free code.
   a) Remember Dykstra's dictum.
   b) If you knew the code was error free, then by the Red Queen's logic
    you wouldn't even need to check for errors, and there would be no
    need for exit statements.  The contrapositive is that if you put
    checks in the code, you are implicitly admitting that your code
    might not be error free.  And there's the rub:  you cannot possibly
    prove that during deployment (as opposed to during testing) using
    a _problem amplifier_ won't make things worse rather than better.

Whatever happened to doing what's best for the customer?  Doing what's
most convenient for the programmer during testing, while making things
worse for the customer during deployment ... that seems remarkably
unprofessional.

Last but not least, I object (again!) to the false dichotomy, i.e.
the allegation that exceptional conditions must either
   a) result in an abort, or
   b) go undetected.


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