Unpredictable GPGME bug

Marcus Brinkmann Marcus.Brinkmann at ruhr-uni-bochum.de
Mon May 27 14:54:02 CEST 2002

On Mon, May 27, 2002 at 05:12:24AM -0500, Robert J. Hansen wrote:
> Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
> bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
> grab all sorts of string data for a given key, and sometimes it will be 
> able to grab a string representation of the algorithm type and other times 
> it'll segfault.  The offending snippet of code looks like:
> GpgmeKey _key;
> std::string _algo;
> _algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);
> ... Maybe one time in ten, that line of code will segfault.  

What do you mean?  one out of ten times you run this on the same key, or for
one out of ten keys?

Let's look at the code:
      for (k = &key->keys; k && idx; k=k->next, idx--)
      if (k)
        val = pkalgo_to_string (k->key_algo);

So, if _key is really a key (and not NULL itself), which contains at least
one subkey (key->keys)), then this can not return NULL, because
pkalgo_to_string doesn't return NULL.

You could let it crash in gdb and check what the key and key->keys look
like in the case it is failing.

> gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
> make a C++ std::string out of a NULL pointer is an instant segfault.
> This has happened for other string quantities, such as usernames, etc.  
> For now, my solution is to assign the result of g_k_g_s_a() to a const 
> char*, test the const char* against NULL, and then assign either the const 
> char* to _algo or else assign "Unassigned" to _algo.  However, this is 
> fairly inelegant given that we could just fix the GPGME code.  :)

Most properties are optional and can return NULL, so you must catch the NULL
case anyway.


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus at gnu.org
Marcus.Brinkmann at ruhr-uni-bochum.de

More information about the Gnupg-devel mailing list