Looking at the GPGME code the ERROR stati don't matter because they are only used to return a better error code in case an operation failed. The specific ones are not even recognized.

No info received.

No more complaints thus time to close.

Please put

I ran gpgconf --kill gpg-agent and then the suggested command for i in {1..10}; do gpg -v --no-tty --verbose -o - encrypted.gpg 2>mylog.$i > /dev/null & done. (I was already running with --verbose, does -v add something else?)

In the interests of completeness I also tried it on a much larger file (1GB) which was both signed and encrypted. I also set the decryption to show the session key just to confirm it was decrypting since the plaintext was being sent to /dev/null.

I am unable to replicate this on OS X 10.9 Mavericks.

Running with -v would really be helpful.

I made a large file for testing, but it doesn't matter. There's an arbitrary parallel limit where gpg will crash.

We need a way to replicate your problem, a few questions first:

sorry, i haven't had time to test gpgme with those changes myself. i hope someone can do so.

The background of my earlier comment was that I didn't tested GPGME in this regard.

if gpgme doesn't rely on the return value, but instead on parsing the --status-fd for errors, then there will still be an ERROR printed:

Okay. So for GPGME should we add --no-keyring if --override-session-key is also enabled? I think this would be better than relying on the fact that gpgme ignores the returned error code.

yes, it looks like using --no-keyring does change the return code from 2 to 0 for me.

@dkg does --no-keyring solves the problem for you?

We assume that this has meanwhile been fixed.

Thanks for the clarification.

Which is the correct way to handle this. We merely gave the MDC packet a standard packet structure so to help with debugging. Decryption needs to defer the 22 bytes to be able to detect the MDC packet.

Perhaps, the missing length information in compressed data packet is confusing. The length can be determined by the assumption of existence of 22-byte MDC packet.

Here is my understanding.

I can see MDC packet of 22-byte (which starts by 0xd3 0x14, and then 20-byte SHA-1 hash), when SEIP data packet is decrypted.
I don't see your situation.
How about with no compression (-z 0)? I mean, compression is not applied to MDC packet.

There is no way for us to fix. It is a shell issue.

The “this” is used so that we don't have too many strings to translate.
I added a call to print_further_info which will in --verbose mode explain it.

@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?

We won't do that. Those with badly encoded user ids should create new keys or meanwhile have done so. The whole charset back and forth encoding adds a lot of complexity for some legacy applications. Frankly I would like to get rid of all code conversions and stick to utf-8.

In T3464 is is described how you can do it. Sure, in your case you want to have a home directory so that the agent and pinentry can work. --no-keyring makes sure that a decryption with a private key can't happen. How we have the cache for symmetric encrypted data which you can disable with --no-symkey-cache.

I'm sorry but the explanation you give does not address the original issue I described, and which dkg then clarified. The discussion about AE is tangentially related, but the issue I described relates to the gpg interface:

To use encryption and for both purposes: encryption and authentication.

I was already implementing a --no-homedir when I figured that we have --no-keyring. Using that with any homedir fulfills the requested purpose.

Will be in 2.2.10

Thank you!

Will be in 2.2.10

Backport done for 2.2.10

AFAICS this is now implemented. We have the option --with-key-origin and even support in GPGME.

Without KEYLIST_MODE_WKD I also can't implement the desired behavior in a MUA using GnuPG.

Why the restriction to keyorg wkd ?

Done. To be released with 2.2.10.

A workaround for this until the HTTP client is fixed is to just use curl instead:

I am running into the same exact issue. It seems that dirmng is incorrectly attempting to resolve the addresses for the keyservers despite having been given an HTTP proxy to connect through.

Fixed for 2.2.9.

To be released with 2.2.9

Agreed, after the verification succeeds the caller can (and probably will) check the signature notations.

re: last question: Marking a notation as recognized does not mean gpg does do anything with it or that it demands this notation. The latter can be handled by the caller. For example, gpg knows about "preferred-email-encoding@pgp.com" but does not apply any semantic to it.

Actually the --locate-key command differs from the implicit use of locate key code when encrypting to a mail address.
After importing the expired key and running for example

Won't fix for 2.2 or CFB encryption.

My bad. I looked at the wrong working copy. Will pick that commit.

No, it is your fix: rG278d87465685: gpg: Clear the symmetric passphrase cache for encrypted session keys..
Please cherry pick it to 2.2 branch.

Thanks. The entire getkey.c code better needs a complete overhaul for before we add v5 keys.

We have a workaround thus lowering the priority.

It seems @gniibe fixed that en-passant in master. At least I can only replicate this with 2.2.

Maybe a first step would be a "KEYLIST_MODE_WKD" which sets "auto-key-locate clear,nodefault,wkd" (Would be nice for T3910 ) or just a ctx_flag "auto-key-locate" so that the caller can decide?

Attaching files is gone, but here they are inline:

Ahh there we go... I just did a --recv-keys to update from the keyserver and that picked up the extended expiration date.

The problem here is that we we did not sync the pubring with the secring in old version (2.1 removed the secring concept also due to that syncing problem). Now if we migrate (or plainly import a secring.gpg), gpg does not see any updated self-signatures and this is the reason why outdated self-signatures are used.

GnuPG itself does that in in gnupg/g10/migrate.c. We need to fixed this.

Do we have an update on this? I seem to be having similar issue. Cannot import a key from my old gpg 1.x version to gpg 2.x version

Yes, closing.

So we had two releases with the fist. Can we set this bug to resolved?

fwiw, i agree that if there's any security vulnerability here, it is in the verification side, not the creation side.

Yep. ?

Fixed in 1.4, 2.2 and master. New releases will be done soon. Note that there is no need for a new gpg4win release because GPGME is not affected.

Okay. Thanks for looking into this.

In the meantime, I upgraded my Fedora installation so I won't be able to reproduce in the same circumstances. I suggest we close the issue for now. I will reopen if I manage to reproduce.

I tried this with the current 2.2 branch and master and was not able to replicate it. The stubs are all deleted as expected. I also checked the commit log since 2.2.6 and didn't found anything which indicated that such a bug was fixed.

See rG26bce2f01d2029ea2b8a8dbbe36118e3c83c5cba for a description of the problem and its fix.
Thanks for reporting.

Better?