GnuTLS (libgrypt really) and Postfix

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

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.

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.

It is the same rationale why defining NDEBUG in production code is a
Bad Thing.

>   2) If used in a threaded environment, it wants to have access to
>      thread primitives.  The primary reason was for RNG pool locking
>      (where it is critical), but I think the primitives are now used
>      in other places too.  GnuTLS is thread agnostic, so it can't
>      initialize libgcrypt properly.

Against our advise Nikos rejected to implement a proper
initialization.  Libraries and threading is actually a deep problem.
It usually works well on GNU/Linux systems but this is more of
coincidence than by design.  We did quite some research on this and
experimented with different ways of automagically initializing the
thread primitives correctly; they all fail either at runtime or create
headaches when trying to write proper build rules.  The current
approach is by far the most flexible and safest.  But yes, the fact
that one library needs an initialization can't be hidden from the
application even if the application is using the lib only indirectly
(Foo->OpenLDAP->GnuTLS->Libgcrypt).

Background: The problem stems from the fact that there are more than
one thread implementations available and used.  Mixing them in one
process cries for problems.  There are quite a couple of libs taking
the putatively easy approach of using pthreads.  Applications using
another thread implementaion (e.g. Pth to make auditing possible) will
then sooner or later run into grave problems.

> list.  I think the Linux /dev/urandom implementation is sub-optimal.

This is known since Ted Ts'o wrote /dev/random and justified by
requirement of the Linux hackers to keep the memory use by a minimal
Linux build low. 


Shalom-Salam,

   Werner




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