gpgme_data_seek with SEEK_END on memory-based data fails

[Leo Gaspard]

(I already sent this mail, but as it was at a time I had a poor internet 
connection and I didn't get any answer, I'm going to repost it, to make sure the 
mail was sent.)

On 13/08/2012 20:23, Werner Koch wrote:
> On Mon, 13 Aug 2012 17:07, ekleog at gmail.com said:
>
>> Yes, I saw GPGME_KEYLIST_MODE_* flags. But there are no way of
>> selecting the keyserver to use directly from GPGME. So the only way
>> would be to modify gpg.conf before each operation ?
>
> Right.  Note that the keyservesr sync themselfs anyway.

Yes. But concentrating the charge of all "my" users on a single server isn't
very good, and at my house round-robin DNS such as keys.gnupg.net have a really
long response time, while e.g. pgp.mit.edu is really fast.
So I built a list of some 79 keyservers (based on the peers each server says it
syncs with), and will have my app choose a random one upon firefox startup. This
should speed things up.

>>   * gpgme.c : The only externally-visible API change : adding
>> gpgme_set|get_keyserver. The objective of the patch
>
> That is an API extension, so in general not a problem.  However, if we
> add it we need to maintain it virtually forever.  Thus I need to see a
> very good reason why you need it.  Note that I consider keyservers an
> implementation detail of GnuPG and thus nothing which should go into an
> “...made easy” API.

We already have GPGME_KEYLIST_MODE_EXTERN, which specifies from where to look
for the keys. This could also be considered as a GnuPG implementation detail.

And, anyway, maintaining them "forever" isn't a really hard issue : GnuPG has it
in its "API", meaning the "--keyserver" will always be valid. Which means that,
as long as GPGME will use GPG under the hood, it will work. If the dependency is
ever reversed, GPGME will have to provide a get|set_keyserver for GPG to use. If
both ever depend on a third tool, this third tool will have to provide such
functions, an GPGME will use them as easily as GPG will do.

Also, you could argue GPGME_KEYLIST_MODE_EXTERN is a useful extension in that it
allows to make an offline application, or to optimize keylisting, or such things.
But setting the keyserver is almost as useful : it allows to use a local
keyserver, or to use some keyserver not synchronizing with the others
(keyserver.pgp.net ?), etc.

Finally, I understood the "made easy" as meaning "don't parse things you're
almost sure to fail parsing correctly, and leave the harness of parsing to
people who know GPG's output better than you, because they chose it".

As a last statement, I believe (but that's only my humble opinion) that GPGME
should offer as much options as GPG does, so that one doesn't have to hesitate
between parsing GPG's output (developper-time-consuming, error-prone), and using
GPGME (fast-use, secure, error-free).

Here's the end of my plea.

If others could say their opinion about this patch, maybe could that help
choosing whether it should be integrated or not.

Cheers,

Leo