Mailing List Archive: GnuPG: devel

gpgme_data_seek with SEEK_END on memory-based data fails

Index | Next | Previous | View Threaded

ekleog at gmail

Jul 28, 2012, 11:51 AM

Post #1 of 13 (310 views)
Permalink

gpgme_data_seek with SEEK_END on memory-based data fails

Hello all !

I recently stumbled upon a strange result while using gpgme_data_seek(data, off,
SEEK_END).

So, I read the source code for this function (and had a quite hard time crawling
to finally find mem_seek).

It looks like there is an error in the function : the offset is negative but is
then substracted from the position, which results in an out-of-bounds pointer
and then in a crash.

Proposed "patch" : file "src/data-mem.c", line 140, turn the "minus" into a "plus".

Hope that helps,

Leo Gaspard

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

marcus.brinkmann at ruhr-uni-bochum

Jul 28, 2012, 1:12 PM

Post #2 of 13 (289 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On 07/28/2012 08:51 PM, Leo Gaspard wrote:
> Proposed "patch" : file "src/data-mem.c", line 140, turn the "minus"
> into a "plus".

Nice catch. Surely nobody ever used that before :)

Fixed in 83e74202cd7c4c975d149c49e2507fdb0e60ef32

Thanks,
Marcus

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

ekleog at gmail

Jul 28, 2012, 2:18 PM

Post #3 of 13 (291 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On 28/07/2012 22:12, Marcus Brinkmann wrote:
> On 07/28/2012 08:51 PM, Leo Gaspard wrote:
>> Proposed "patch" : file "src/data-mem.c", line 140, turn the "minus"
>> into a "plus".
>
> Nice catch. Surely nobody ever used that before :)

Hello Marcus,

I have to admit that I probably wouldn't have noticed it if I wasn't writing a
javascript wrapper for gpgme.

Giving you some context, I'm trying to write a firefox addon to extend PGP
signing and encrypting to webmails, so as to allow the average grandmother to
use PGP, as she doesn't have thunderbird installed and wouldn't understand
enigmail's instructions. Let alone mutt & co.
So, I was writing the test suite when I found this bug.
You may look at mailock on github, if you want to have a look at the test suite.
Interesting files in there are lib/gpgme/low.js (the low-level API,
retranscription of gpgme to javascript) and test/test-gpgme-low.js (the test suite).

So... Here is the end of my ad campaign. :)

Cheers,
Leo

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Jul 29, 2012, 2:41 AM

Post #4 of 13 (287 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On Sat, 28 Jul 2012 23:18, ekleog [at] gmail said:

> Giving you some context, I'm trying to write a firefox addon to extend
> PGP signing and encrypting to webmails, so as to allow the average

That is really good news. Thanks for tackling the major problem with
webmail.

Let us know if you think gpgme works correct for you now so that we can
do a new release right in time for Debian Wheezy.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

ekleog at gmail

Jul 29, 2012, 11:25 AM

Post #5 of 13 (286 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On 29/07/2012 11:41, Werner Koch wrote:
> Let us know if you think gpgme works correct for you now so that we can
> do a new release right in time for Debian Wheezy.

Hello Werner,

I didn't compile gpgme on my own, and so can't tell you whether it works for
sure. Moreover, I didn't implement the whole GPGME interface in JS at the
moment, and so can't tell whether there are any other issue with anything after
manual section 7.5.4.

But the two issues I noticed should now be fixed, according to what I saw in the
commits. I removed them from my tests, waiting for the release to come in
archlinux's repositories, but all the other tests work right.

However, before a release, I'd like t know... is there a way to get/set through
GPGME the keyserver used by the context ? I figured out that there is a GPGCONF
protocol used by GPGME, but didn't find any documentation on how to use it.
(BTW, it is not in the doc, only in the code, so that could be the answer)
If there isn't yet, it could be an interesting feature to add before the
release, as it isn't yet a really featureful release, isn't it ?
If this feature isn't there yet, and you think it might be useful (as I do),
maybe might I help by writing a patch for it ? (just looked at the source, looks
like this would require adding gpgme_get|set_keyserver, adding a const char
*keyserver property in the context, and adding a flag check to gpg_encrypt_sign
& co.).
However, I wouldn't be able to write the patch before 15 days, as I'm going to
take an aikido course in Japan. :D

Cheers & HTH,

Leo

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

ekleog at gmail

Jul 29, 2012, 1:59 PM

Post #6 of 13 (282 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

Hello again,

I finally decided to write the patch immediately.

I placed the output of "git format-patch -M origin/master" in the attachment.

Things that are still TODO:
* Adapt gpgme-tool.c ? (Didn't have enough time to understand what it was
about... a CLI tool ?)
* Is there a keyserver concept for gpgsm ?
* Write the doc.
* Check it (builds and) runs the tests : I didn't have enough time to read doc
on compiling & testing.

I hope I didn't break any binary compatibility or such.

Is there anything I should do (legal stuff, copyright waiver or such things) ?
(It's my first "real" participation in an open-source project.)
I'll go away tomorrow for two weeks, so please answer quickly if you want me to
do such things quickly !

Hope that helps,

Leo

Attachments:

0001-Allow-to-set-a-context-s-keyserver.patch (15.0 KB)

wk at gnupg

Jul 30, 2012, 2:03 AM

Post #7 of 13 (284 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On Sun, 29 Jul 2012 20:25, ekleog [at] gmail said:

> However, before a release, I'd like t know... is there a way to
> get/set through GPGME the keyserver used by the context ? I figured
> out that there is a GPGCONF protocol used by GPGME, but didn't find

This is not per context setting but global one. Yes, the documentation
is quite limited. We did this as an experimental interface once and
only recently changed it to a supported interface.

> If there isn't yet, it could be an interesting feature to add before
> the release, as it isn't yet a really featureful release, isn't it ?

For various reasons it can't be done with a per context setting. In
fact 2.1 will have some substantially changed to the keyserver
infrastructure. You need to use gpgconf to modify the global (well, per
user) configuration.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

ekleog at gmail

Jul 30, 2012, 3:42 AM

Post #8 of 13 (284 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On 30/07/2012 11:03, Werner Koch wrote:
> On Sun, 29 Jul 2012 20:25, ekleog [at] gmail said:
>> If there isn't yet, it could be an interesting feature to add before
>> the release, as it isn't yet a really featureful release, isn't it ?
>
> For various reasons it can't be done with a per context setting. In
> fact 2.1 will have some substantially changed to the keyserver
> infrastructure. You need to use gpgconf to modify the global (well, per
> user) configuration.

So, I suppose the patch I sent on the mailing list yesterday doesn't work ?
It adds the --keyserver <keyserver> option to gpg for imports and exports. I
don't really understand how gpgme works underneath, but, as --armor & co. work,
I supposed it should work, like any other flag, isn't it ?

Hope that helps,

Leo

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Jul 30, 2012, 9:28 AM

Post #9 of 13 (283 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On Mon, 30 Jul 2012 12:42, ekleog [at] gmail said:

> So, I suppose the patch I sent on the mailing list yesterday doesn't work ?

I have not said this ;-). I have two problems with the patch:

- It is very specific for keyservers and not a general way to describe,
well, what keyservers are. We already have ways to locate keys from
remote resources. See the GPGME_KEYLIST_MODE_* flags. This needs to
be unified with other uses of the keys. And it also needs to be in
line with planned or already done changes in 2.1.

- You break the ABI and API with your patch - this is not acceptable
for a stable library.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

ekleog at gmail

Aug 13, 2012, 8:07 AM

Post #10 of 13 (261 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

First of all, sorry for having been late answering.

On 30/07/2012 18:28, Werner Koch wrote:
> On Mon, 30 Jul 2012 12:42, ekleog [at] gmail said:
>
>> So, I suppose the patch I sent on the mailing list yesterday doesn't work ?
>
> I have not said this ;-). I have two problems with the patch:
>
> - It is very specific for keyservers and not a general way to describe,
> well, what keyservers are. We already have ways to locate keys from
> remote resources. See the GPGME_KEYLIST_MODE_* flags. This needs to
> be unified with other uses of the keys. And it also needs to be in
> line with planned or already done changes in 2.1.

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 ?

That's why I thought a keyserver (i.e. the server with which to interact, maybe
another name could be better ? I used OpenPGP name, because I don't know GPGSM
enough yet.) setting could be useful.

> - You break the ABI and API with your patch - this is not acceptable
> for a stable library.

I thought quite a bit about this, and didn't find out in which way.

Summarizing the changes :

* context.h : Added a keyserver variable to struct gpgme_context. As the
structure is fully opaque from the library user, I don't think it breaks any
API. (except maybe the internal one ?) And, as it is referred from "user" code
only through pointers, there is no ABI breakage, right ?

* engine-backend.h ; engine-gpg.h ; engine-gpg.c ; engine-gpgsm.c ; engine.c ;
engine.h ; export.c ; keylist.c : Some small API change, but it's only on
internal functions, it's not an issue, is it ?

* gpgme.c : The only externally-visible API change : adding
gpgme_set|get_keyserver. The objective of the patch

Am I wrong ?

Cheers,

Leo

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

ekleog at gmail

Aug 17, 2012, 9:00 AM

Post #11 of 13 (247 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On 13/08/2012 20:23, Werner Koch wrote:
> On Mon, 13 Aug 2012 17:07, ekleog [at] gmail 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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

ekleog at gmail

Aug 20, 2012, 3:41 PM

Post #12 of 13 (234 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

(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 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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Sep 26, 2012, 12:59 AM

Post #13 of 13 (139 views)
Permalink

Re: gpgme_data_seek with SEEK_END on memory-based data fails [In reply to]

On Tue, 21 Aug 2012 00:41, ekleog [at] gmail said:

> 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.

The problem here is that we have the external keyserver helpers which
are stateless. They need to do the DNS queries again and again. With
2.1 this will go a way because the dirmngr takes care of keyserver
access and is able to maintain a list of responsive keyservers from a
round-robin address.

> 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.

No where to look for the keys but to do an external lookup. External
lookups have different properties: They may take long, they may return
inconsistent results over time, and they have privacy implications.
The initial reason for having such a flag is for X.509 LDAP lookups

We try to GPGME's API protocol neutral: One API for all protocols.
Keyservers are very OpenPGP specific.

> 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.

Now, why to you want to change it with every operation? I still
consider it a configuration option and not a property of a concrete
operation.

> 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),

GPG has way too many options. GPGME allows to access a subset of the
configuration options using its configuration API. If there is a useful
runtime option, we can consider to add it to GPGME.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads