On Mon, Feb 13, 2006 at 11:29:00AM +0100, Simon Josefsson wrote:
> 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.
>
Yeah, right, really easy when GnuTLS is called from the system LDAP
libraries... In any case the only way for the handler to avoid
process death is longjmp() to a context created before calling
GnuTLS/libgcrypt()... not a particularly robust solution.
void
_gcry_log_fatal( const char *fmt, ... )
{
va_list arg_ptr ;
va_start( arg_ptr, fmt ) ;
_gcry_logv( GCRY_LOG_FATAL, fmt, arg_ptr );
va_end(arg_ptr);
abort(); /* never called, but it makes the compiler happy */
}
the handler is invoked in _gcry_logv()... The Postfix TLS functionality
is built over OpenSSL (not GnuTLS) and OpenSSL has an error stack, which
the application can process as it sees fit. The libgrypt approach to
error reporting is not acceptable.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAIL Morgan Stanley confidentiality or privilege,
and use is prohibited.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
