GPGME recipients Q: is this a bug or a feature?

[Robert J. Hansen]

In my C++ wrappers for GPGME, I've got a helper function that does the 
following:


// _recips is a protected class variable: a linked list of strings
// representing 8-byte key IDs (16 hex glyphs).  You can call a
// string method, c_str(), to turn a string into a C-style string.

GpgmeRecipients makeRecipients()
{
  GpgmeRecipients recips;
  gpgme_recipients_new(&recips);
  list<string>::const_iter iter = _recips.begin();
  if (_recips.empty())
    throw GPGMEerr("No Recipients");
  while (iter != _recips.end())
  {
    errswitch(gpgme_recipients_add_name
      (recips, iter->c_str()));
    iter++;
  }
  return recips;
}

... Pretty simple, I think.  There's not a lot of room for it to go 
haywire, but it does.  It constructs valid GpgmeRecipients for all valid 
inputs--or, at least, all valid inputs I've tested--and throws exceptions 
appropriately on invalid inputs.

However.

When I attempt to use this GpgmeRecipients for an encryption or 
encrypt-and-sign operation, it works great provided all recipients are 
trusted (signed by an ultimately-trusted key or a trusted introducer).  If 
any recipients aren't trusted, GPGME returns a "no recipients" code when I 
try to encrypt or encrypt/sign.

A call to gpgme_recipients_count() immediately before the encryption 
operation shows that we have a populated GpgmeRecipients.

Now, I've looked in the manual, and so far I haven't been able to find any 
passage which clearly states whether this is a bug or a feature.  Can 
someone please refer me to what the expected behavior is, and how I can 
force encryption to an untrusted key?

Thanks. :)