Feature req for GPGME

[Robert J. Hansen]

> The reason why we don't have such an interface is that it is not extensible:

Not necessarily.  You can leave void*s and const-char*s unused in the
structure and mark them "for future expansion", which ameliorates the
extensibility problem by reducing the need to change the structure. 
Doesn't remove the problem, no, just ameliorates it.

> If you change the structure, you break binary compatibility.  It's very
> simple to write a small wrapper that reads out the needed attributes and
> puts them in a struct, and you can adopt that to your own needs.

Yep, but where I'm coming from is--if we're expecting people to recreate
the same piece of functionality for themselves, it just offends my
hackish ideal that people shouldn't have to reinvent the wheel
needlessly.  :)

Let me make a different pitch for the issue: not doing it creates a
(potential) security issue.  A remote one, but real.

Imagine we have a function,

GpgmeErr
gpgme_key_get_struct(const char *filter, GpgmeKeyStruct *ks, int *num)

which will check through the keydb for all keys matching filter, and
populate an array of keystructs starting at ks, and returning the number
of keys found in num.

Doing things this way means we could isolate the GpgmeCtx and GpgmeKeys
involved all within the gpgme_key_get_struct function.  That, IMO, is a
good idea; if we were to do that, we could guarantee no GpgmeCtxes would
fail to be _release()d afterwards, no GpgmeKeys would fail to be
unref()ed afterwards, etc.  

Otherwise, if everybody rolls their own, I imagine a lot of people will
wind up holding onto GpgmeKeys and GpgmeCtxes long after they should. 
I'm not sure whether or not those floating Ctxes and Keys could be used
to attack the system, but I know we're safer if we remove the chance for
them to happen.

-- 
Geek Code: GAT d- s+:+ a27 C++(+++)$ ULB++>++++ P++ L+++>++++ E W+ N+ w
           PS+ PE++ Y++ PGP++ t+ 5++ X-- R tv b+++ DI++ D--- G+ e++ h*
           r* y+*