GnuTLS (libgrypt really) and Postfix

[Simon Josefsson]

Werner Koch <wk at gnupg.org> writes:

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

That /dev/random doesn't exist seem like a quite possible state to me.
The application would want to shut down gracefully when the library
detect that condition.  The application may be processing files in
different threads.

Further, a library is not in a good position to report errors.  A
users will sit there wondering why Postfix, or some other complex
application died, without any clues.  Returning an error and providing
a foo_strerror() function at least make it possible to report a useful
error to the user.

I would agree if we are only talking about truly fatal cases, like
asserts() to check explicit pre-conditions for a function, but I
disagree when we move into the area if easily anticipated problems.

However, looking at the code, it is possible for Postfix to handle
this.  They could have installed a log handler with libgcrypt, and
make sure to shut down gracefully if the log level is FATAL.  The
recommendation to avoid GnuTLS because libgcrypt calls exit suggest
that the Postfix developers didn't care to investigate how to use
GnuTLS and libgcrypt properly.  So I don't think there is any real
reason to change code in libgcrypt here.  Postfix could be changed, if
they care about GnuTLS/libgcrypt.

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

Agreed.

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

I'd say that the most flexible approach for a library is to write
thread-safe code that doesn't need access to mutexes to work properly.

Implementing the RNG functions like this is a challenge, and may
require kernel-level support (see below), but giving up and requiring
thread hooks seem sub-optimal.

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

That seem like a poor argument to me.  It may be valid for embedded
devices, but for most desktop PCs, Linux should provide a useful
/dev/urandom.

It seems that it would be possible to write a new /dev/*random
implementation that is more useful by libgcrypt and other RNG
libraries.

Thanks,
Simon

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