gpgme assert crash during op_encrypt_sign

J Robert Ray jrray at
Tue Aug 20 08:15:02 CEST 2002

Hash: SHA1


I'm getting an assertion during gpgme_op_encrypt_sign():
data.c:694: _gpgme_data_append: Assertion 'dh' failed.

The line number may not line up with the latest CVS version, I'm using
0.3.6 because newer versions fail to compile on me, an error building
the documentation actually.  But anyway the problem seems to still be in
the latest version, looking at the source in CVS.

I've determined the assertion happens only when I have untrusted
recipients in the recipient list.  I have to sign and trust fully a key
before the call succeeds (and doesn't fail the assert).  It's been hard
for to test, but I believe if I have multiple recipients, and I've
signed/trusted the first recipient, the call succeeds.  But if I haven't
signed/trusted the first one, it asserts.

The problem seems to be in encrypt_sign_status_handler, around here:

~  _gpgme_sign_status_handler (ctx, code, args);
~  if (code == STATUS_EOF && encrypt_info)
~    _gpgme_data_append (ctx->op_info, encrypt_info, encrypt_info_len);

The assertion happens because ctx->op_info is NULL.  It is set to NULL
right before _gpgme_sign_status_handler is called, but in
_gpgme_sign_status_handler it is not always assigned a new value:

~    case STATUS_EOF:
~      if (ctx->result.sign->okay)
~        {
~          append_xml_siginfo (&ctx->result.sign->xmlinfo, NULL);
~          _gpgme_set_op_info (ctx, ctx->result.sign->xmlinfo);
~          ctx->result.sign->xmlinfo = NULL;
~        }
~      if (!ctx->error && !ctx->result.sign->okay)
~        ctx->error = mk_error (No_Data); /* Hmmm: choose a better error? */
~      break;

ctx->op_info is only set to something if ctx->result.sign->okay is true,
otherwise an error condition is set.  When this function returns, the
error condition is not tested for.

I can see this is likely the problem, but I'm familiar with the code and
don't know how to fix it.

Based on the documentation, I thought this should encrypt for as many
recipients as possible, and return that some recipients were bad, or
that they were all bad.  Is it possible to find out which keys are bad
and which are good?

I've had to work around the assert by adding recipicents with validity
set to full.  This isn't good because I end up trusting any and all keys.


- - Robert

- --
Key fingerprint = BEA9 490C D2B9 AD83 E88B  3148 3136 34E4 BB92 9E54
Version: GnuPG v1.1.90-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla -


More information about the Gnupg-devel mailing list