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
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
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
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel