gpgme_data_seek with SEEK_END on memory-based data fails

Leo Gaspard ekleog at gmail.com
Fri Aug 17 18:00:19 CEST 2012


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



More information about the Gnupg-devel mailing list