Here is the list:

• libgcrypt
• libassuan
• ntbtls
• gpgme : autogen.sh is ready
• npth

Just tried this but can't replicate it:

$ ../g10/gpg -dv <1.msg --override-session-key 7:D6E1027D58A0CB047C41EA881A137197 --status-fd 2 
gpg: public key is 7F3B7ED4319BCCA8
[GNUPG:] ENC_TO 7F3B7ED4319BCCA8 18 0
gpg: encrypted with ECDH key, ID 7F3B7ED4319BCCA8
[GNUPG:] BEGIN_DECRYPTION
gpg: AES encrypted data
[GNUPG:] DECRYPTION_INFO 2 7
gpg: original file name=''
[GNUPG:] PLAINTEXT 62 1508859245 
[GNUPG:] PLAINTEXT_LENGTH 68
"Well hello there Charlie Brown, you blockhead."
                -- Lucy Van Pelt
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION
$ echo $?
0
$ gpg -k 7F3B7ED4319BCCA8
gpg: error reading key: No public key

gpgme does not known about return codes because it uses a double fork approach. However, certain staus lines could have the same effect.

Hm, perhaps this non-zero return code is due to not being able to write to the GNUPGHOME directory, actually. It goes away when GNUPGHOME is writable. That doesn't make sense either -- this operation doesn't actually depend on being able to write to GNUPGHOME, so it shouldn't return a different error code if GNUPGHOME is unwritable.

gpgme shall provide an interface for commonly required tasks but it shall not expose everything from gpg.

I guess it depends on whether you want gpgme to be an interface to OpenPGP certificates more generally (in which case, exposing the primary flag would be useful), or just a gpg frontend (in which case, the current behavior might be ok)

Right, but gpg has a strategy to figure out what it considers the primary (ie. the user id commonly printed). If we would merely convey the primary key flag to gpgme, gpgme or the gpgme calling application still needs to figure out what it considers the primary key - that might be different from what gpg shows.

But there can be several user IDs that are marked primary, right? I know that gpg tries to not let that happen, but there are other OpenPGP toolkits out there, and composite/hybridized keys, etc where this could happen.

Well, it is already there:

gpg always returns the primary user id first. (see gnupg/g10.keylist.org:reorder_keyblock). gpgme keeps this order and thus the first user +id in the linked list is the primary user id. If the primary user id flag is not set the first is the same what gpg considers the primary user id. I can add this to the documentation.

No. GPGME can't check return codes because it uses a double fork approach.

This is more or less what gpgme does/sees when loopback mode is enabled / disabled:

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?