In T2919#102889, @stbuehler wrote:

I think bad.trace is very similar in the errors (chan_9 instead of chan_7); the difference is probably that the "bad mail" is not using a detached signature (possibly even encrypted), so mutt cannot find the body without actually decoding the message through gpgsm; the "good mail " is using a detached signature, and the body is the first part of a multi-part message which mutt can decode itself; it still can't verify the signature.

Sure: http://netbsd.gw.com/cgi-bin/man-cgi?getenv_r++NetBSD-current

Do you have the specs for getenv_r? I can't find such a thing on FreeBSD or Debian

I think bad.trace is very similar in the errors (chan_9 instead of chan_7); the difference is probably that the "bad mail" is not using a detached signature (possibly even encrypted), so mutt cannot find the body without actually decoding the message through gpgsm; the "good mail " is using a detached signature, and the body is the first part of a multi-part message which mutt can decode itself; it still can't verify the signature.

Sure. Here's the stdout and stderr for gpgme-1.9 with GPGME_DEBUG=9 and

In T2919#102001, @stbuehler wrote:

I just had a look at good.trace and it seems gpgsm --server exits instantly (chan_7 <- [eof]). The path seems to be correct though (/usr/pkg/bin/gpgsm), and /usr/pkg/bin/gpgsm --version reads (the first 79 bytes):

gpgsm (GnuPG) 2.1.18
libgcrypt 1.7.6
libksba 1.3.5
Copyright (C) 2017 Free Soft

The --version call passes the full path in argv[0] (but the full path is always passed as first argument to execv, so it shouldn't make a difference).

Sadly it seems there is no error message from gpgsm, and also the exit code isn't shown. Maybe you could try running gpgsm --server manually; it should greet you with OK GNU Privacy Guard's S/M server * ready. An strace log might provide more insight why gpgsm --server fails.

Please see my comments on rM9f24e6c9010e171fd11c5cdac797cb8ce2e501dd

I would suggest that MUAs who care about privacy do no use S/MIME at all or at least direct GPGME to not consider CRLs during signature verification. We don't have such a feature in GPGME right now but I think that is the right place to add it. X.509 is way to complicated to avoid meta data leaks.

So it fails after a timeout. Which probably means that the conf->sync calls timeout which probably means that some gpgme process call to gpgconf hangs. Maybe some IO Flush that does not happen correctly on MIPS. But this is pure guessing.

Unfortunately, even building for two Python versions is a bit of a hassle with the existing autoconf framework for Python. I did that when porting the Python bindings back to Python2 after we decided to also support 2 so that people could start to use our bindings even if they still need Python2. I don't see us extending it for more versions.

Merged, thanks for the reminder.

this is also https://bugs.debian.org/866555

I guess for older releases it is less relevant to have very accurate version information. From now on this is more a regular maintenance task than a unit of work, so I am closing it.

Gave it a head-start.

This is probably broken since Werner enabled descriptor passing by default in 5090f6f24. The analysis in https://dev.gnupg.org/T2919#99901 is correct, but it's not enough to put the operational error in the right place. Also, the calls to _gpgme_wait_one have to be replaced by _gpgme_wait_one_ext. The change overall will be somewhat destabilizing.

Now you can do this:

gpgme_data_t are first class objects with an API to create and destroy them, and some articulated rules how to use them (only one thread at a time). gpgme_key_t objects can not be created but only be returned with gpgme_op_keylist_next.

It wasn't a natural thing to do gpgme_op_import because i already had my gpgme_key_t object, which i was using to display an index of available keys to the user.

One way to prevent this mechanically would be to store an identifier for the gpgme_ctx_t object from which the gpgme_key_t object came inside the gpgme_key_t object itself, and then verifying that the keys really came from the same context. But such edge cases seem to be quite rare, and I'd hope that most developers make a tacit assumption that objects stemming from a specific context can not be repurposed in a different context ad lib.

Why wasn't the natural thing for you to do gpgme_op_import?

I'm not sure i understand why i'm "chasing a ghost" -- i'm reporting the experience of a developer (me!) who tried to use gpgme, read all the docs, and was still surprised and dismayed by the metadata leakage.

This should be fixed by a0cc6e01. Just use the new gpgme_op_delete_ext operation with GPGME_DELETE_FORCE flag.

Turns out that 2963 fixed this at the same time.

You are chasing a bit of a ghost there. The operation was originally added for GPGSM to support the IMPORT --re-import command that removes the ephemeral flags from certificates that were previously imported as a side-effect of an external keylist operation. That's where the footnote comes from.

Thanks for the improvements, Marcus!

Well, we need more information to proceed on this. Maybe run with GPGME_DEBUG=9 to see why it fails.

Most of your concerns seem to come from the "move keys" wording, which I removed. I also fixed the return values. The footnote is specific to X.509 peculiars.

Done in 274609ba.

Fixed in 977fc5f0e.

I just tried on an up to date fedora 26 system, and could not reproduce this.

I'm sorry; given the original error message

[-- Error: decryption failed: Invalid value passed to IPC --]

I thought it was the same problem I was having.

Well, at least this works without changing the environment:

The problems I recall were about linking the C library gpgme against MSVC compiled other binaries.

I recall that we had the same problem back in 2010 and solved it. Please describe the ABI differences.

Could be done by adding "--yes" to the command line. Requires a new version of the gpgme_op_delete functions with a flag "force".

Fixed with https://commits.kde.org/kleopatra/3e08e4d25d34140a1d03e02c7bd9d066120d0baa

Ah no. GpgME is not at fault. Kleopatra just eats the status and only shows system error. Have to fix this in kleopatra.

87703dbb86ac8fd8abd23170f8038ea6e3dbde28 was the offender. It called _gpgme_split_fields on a non fatal decrypt error which resulted in a mangled error passed to verify.

Ah! I can now also reproduce it on Linux, I had two gpgme's installed and the wrong one was picked up. Bisect here I come :-)

Do you have a use case?

Thank you very much for addressing this so quickly. I agree that corrupt data needs no further details here.

Thanks. Indeed we should have better error codes. However, passing all error codes from the backend to the user is not useful.

I am using Debian 9 with the packaged versions. For gnupg this is 2.1.18.

@aheinlein we need to know the gnupg version you are using with GPGME.

I've since tried neomutt-20170707 which includes stbuehler's patch, but I see the same error cases as before.

This is not specific to Python, and it may not even be a bug in GPGME, but in gpg. Needs some more investigation.

Fixed in 1e68f93dc547ae75b921e43db35e3599de92e2cb.