Ok, I can understand that now if you use GPGME 1.1.5. This was fixed a long
time ago:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I can not reproduce this. Can you please run this with a gpgme library with
debug symbols so we get a full backtrace out of valgrind?

Please check the version. Do you mean 1.1.6 with Ubuntu patch 4?

Platform info:
Linux <machine> 2.6.24-21-server #1 SMP Tue Oct 21 23:40:13 UTC 2008 x86_64
GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04.2
Release: 8.04
Codename: hardy

I guess we can close this bug.

GPGME has now been thoroughly tested in a multi-threaded environment (Kleopatra
on Windows), and it seems to survive. Closing this vague report.

Closing the report about porting to a non-supported target.

Actually, gpg can not do much if configuration options can't be parsed. GPGME
does not see the exit code due to the double-fork approach.

Closing this report. If further support is required, please reopen.

Trivial patch. Closing bug,.

Note: It also works for gpgme_op_decrypt_verify, but the error code
GPG_ERR_NO_DATA needs to be ignored in this case. This is because we didn't get
a DECRYPTION_OKAY status message, and this is semantically the same as for a
signed but not decrypted file. We can consider making this case better in a
major upgrade when we change the ABI anyway, but not now.

Works fine for me with gpgme_op_verify, which actually runs the gpgme -o command
as you gave it. Did you rewind the output data object before trying to
read the data?

Marcus: Can you please check whether we can easily add this to gpgme_op_decrypt?

Applied to trunk. Unfortunately it didn't made it into 1.1.7.

Background info: My e-mail program is currently calling gpg via fork() and
exec() and is thus very GnuPG version dependent. It does not create such
messages, but can display them. Trying to get rid of the version dependency,
I've tried to switch to GPGME and stumbled about a test message I've received
years ago. Unfortunately the header lines do not mention what mail program was
used for sending.

I was not aware that such OpenPGP messages are actually used. We need to see how
to implement that.

Tested with gnupg2 2.0.9-1 from Debian sid and python-pyme 0.7.0-4.

D50: 154_gpgme-getkey-ambigious.diff

Fixed. See the attached patch or use the current SVN.

I have looked and I can't find how to do this thru environment variables, is
there a way to do this?

You could try to debug GNUPG ((set debug-file and debug-level=guru option).
Maybe that reveals something.

I have upgraded to GnuPG 1.4.7 and pgpme 1.1.4. I am still having the same
problem. I would really like to find a fix for this. I am willing to do
anything to help track this problem down. Any help at all on this?

I put the status to deferred, as the final decision to keep or remove
gpgme_data_seek will be done when the other deprecated interfaces will be removed.

Thanks for the detailed report. I put in your fix (with minor cosmetic
corrections). As for the prototype ttyname_r: I hesitate to put any of the
_SOURCE_ macros in the build unconditionally, as this may trigger other issues.
If you give me the output of ./config.guess on your platform, I will put it in
for that platform (please also verify if defining any of these results in a
proper working build.)

I did a re-installation of the software without any further problems. So it works without errors now.
Thank you for your spupport!

Please, a bit more details

I have sympathy with you, and if gpgme_data_seek were the only user of off_t in
the GPGME API, there would be some force behind your suggestion. However, it
isn't, and I don't think that keeping around multiple interfaces for essentially
the same function is useful in the long run. That said, I have two things that
may help you: