GnuTLS (libgrypt really) and Postfix

Werner Koch wk at gnupg.org
Sun Feb 12 16:25:21 EST 2006


On Sun, 12 Feb 2006 13:46:05 -0500, John Denker said:

> That is a remarkably unprofessional suggestion.  I hope the people
> who write software for autopilots, pacemakers, antilock brakes,
> etc. do not follow this suggestion.

Thus my remark about a independend failsafe system.

I strongly hope that for life critical systems nobody even things
about throwing in a bunch of general purpose libraries and declares
the task as done.  Fortunately these systems have resource constraints
so that such a solution won't come to mind anyway.

> First of all, "impossible" is the wrong word.  If the condition

s,impossible,not foreseen/tested/coded by the developer,

> previous tick's tasks are finished.  What do you do, exit?  If

Yes.  And one of the concurrent running system will take over. In
1969 this system used to be Armstrong, though.

> There are other stories like this, including funny (?) stories of
> what happens if exceptions are not handled so well.

Terminating a process is a well handled exception.  Think of hardware
failure; continue while knowing that tehre is something really weird
going on??

> More generally:  library routines should never exit.  They almost

If you are thinking of exit please mentally translate this to assert.
Still believing one should never call assert(0) in a library?

>   Nitpickers note:  I can imagine a situation where the stack is so
>   messed up that you can't thrown an exception or even return from

Die as soon as you can; kill (getpid(),SIGKILL) might even be
justified in such a situation.  Try to make an attackers life as hard
as possible.  Yes, for life critical systems an attack scenario might
be different to judge and thus the design needs to be different.

Obviously I agree with Ben that that there is no way to know the
current state if something went wrong in unexpected ways.


Shalom-Salam,

   Werner


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



More information about the cryptography mailing list