GPGME recipients Q: is this a bug or a feature?
Robert J. Hansen
rjhansen at inav.net
Fri Jun 28 00:43:02 CEST 2002
In my C++ wrappers for GPGME, I've got a helper function that does the
// _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.
list<string>::const_iter iter = _recips.begin();
throw GPGMEerr("No Recipients");
while (iter != _recips.end())
... 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.
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?
More information about the Gnupg-devel