Inconsisten usage of secure memory? (Debianbug #212329)

[Andreas Metzler]

Hej,
I am trying to make sense out of <http://bugs.debian.org/212329>.

The bug used to manifest in mutt (or gaim) sometimes not being able to
connect, because of "operation is not possible without initialized
secure memory". Mutt is not using gcrypt directly but gnutls.

I think the bug somehow does not re-appear in mutt nowadays, otherwise
abovementioned report would probably show a recent followup. Anyway,
what came out of it was this:

<asuffield> I can't see any way that gnutls could possibly activate
            the secure memory code
<asuffield> it's hardcoded that argument to zero
<asuffield> yup, there are mixed guarded and unguarded calls to 
            gcry_malloc_secure in one of the libgcrypt ciphers
<asuffield> I can't see that being right at all
<asuffield>     hd = secure ? gcry_malloc_secure( n + sizeof( struct 
            gcry_md_context ) )
<asuffield>                 : gcry_malloc(       n + sizeof( struct 
            gcry_md_context ) );
<asuffield> ...
<asuffield>     if( hmac ) {
<asuffield>         ctx->macpads = gcry_malloc_secure( 128 );
<asuffield> that seems logically inconsistant
<asuffield> and the public key cipher doesn't guard the call at all
<asuffield> any of the ciphers using HMAC will break like this

I am not sure whether this is buggy, but I could not find anything in
the documentation about it, and all the things said above still seem
to apply in 1.2.2.
         cu andreas

-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde