Yeah, that's not good enough. You also need to check if literals_seen is 0 before BEGIN_DECRYPTION to catch the case where the plaintext packet comes before the encrypted packet. See https://github.com/das-labor/neopg/commit/30623bcd436a35125f21fe6f29272a5fa7212d3f

I need to revise my statement (partly because fixing gpgme would be quite complicated). Marcus is right in that using the the literals_seen counter is the straightforward way to get this right. And it will fix it also for non-GPGME applications.

@werner, what protocol design rule do you think is not being followed specifically?

From the autocrypt page:

Let me state it again: Using symmetric encryption for authentication is Bad Thing™.

The bugreport was about "use existing key" selecting keygrips and I did try to use "change-usage" (for NIST P-256).

What you try to do is very special and not directl supported. You need to find the keygrip of the subkey (I guess you know that) and enter it as "use existing key" in the add-key sub-command. To change capabilities use the change-usage sub-command which is described in the gpg man page and the online manual.

Workaround is to click cancel so that the next key is tried; right?

I thoroughly tested this again with the released versions. Works very nicely, including the timeout.

Thanks.

Confirmed. it is also not Windows specific.

A strangeness I see is when I am searching for "zitis" on x500.bund.de I get the same key over and over again (until the list is truncated). I'm not sure if the response from the server is wrong or if we have a bug there. If I search for "Telekom" for example I get 10 different certificates, so it works there.

I felt confident enough to push a fix for the console window. The code was obvious and the fix, too.

Yes! Works nicely. I tested with unreachable and invalid servers, and with multiple queries against x500.bund.de and ca.intevation.de all is fine!

No longer happens when the good old ldapwrapper is used.

The hang appears random. It sometimes works 4 out of 5 times.

With latest gpg-error and latest gnupg It still hangs for me after printing the certificate.

Still happens. There are also "BER" errors that seem random.

Thanks @werner for applying the patch. Closing here, since I have been using that patch for several weeks now without ever encountering the bug again.

Hint from @gniibe: gpg --with-colons --list-config curve is a workaround.
So it still should be documented and made accessible from a non-esoteric, non-internal way. ;)

You are welcome :-) I did not know about that 39-Arigato

I changed the title to express the problem.

Thanks for the script.
I confirmed that secring.gpg is not updated when importing key with updated expiration date, by GPG1.
So, for GPG2, it is expired key.

Workaround is implemented in 2.2.6.

That slipped my attention due to the missing gpg22 tag I should have added. Sorry.

Yes. However, I have tested a fix for the empty value.

Have you tried it multiple times? If it's unintialized memory access maybe you got lucky?

I still can't reproduce the crash (on Vista).

Will be in 2.2.6.

Oh, you used a single dash and not a double dash in --armor. That is obviously the problem. As per Unix history all option characters may be combined unless they take an option arg; in that case the arg for the option may go directly after the option letter. We can't change that because lots of people and scripts use -rRECIPIENT.

I see. Got it.

To be released with 2.26 next week

Right with (2) (1) will not occur if the key has been created with GnuPG. However, we have caches in the code path and further rogue software may create creates, interesting keys (tm). Thus I consider it better to explicitly request keys with cert flag set.

The patch has two parts; (1) detecting signature by incapable key and (2) limiting key with relevant capability.
I think that (1) is enough. I wonder with (2), (1) would not occur.

Forget my former comment. We only need to check subkeys becuase the primary key can always certify.
Here is a new revision of the patch:

I have another patch proposal to check the key usage. However, there is a catch-22. We get the usage flags from the key signatures and thus we can only check them after we checked the key signature.

The gpg20 tag was a typo.

Okay. We need to add a FAILURE status so that gpgme can better report this invocation error. Due to the double fork it won't be able to see the exit status. I assume you have the same problem in Enigmail.

In my opinion we should assume that c:/ was meant.

Under Wine it does not crash but returning an empty string is not a good idea in any case. The question is what to do with "c:". The usual meaning is to use the current directory of drive C. But that does not make much sense. Should we simply assume that "c:/" was meant?

Hi Werner. Did you by any chance already find the time to look into the changes?

The use case that @Valodim and @dkg are thinking of probably is using a setup-code that humans use to transfer from one device do another to decrypt a symmetrically encrypted setup-package, this issue is linked from:

https://autocrypt.org/level1.html#setup-message-import

Ok the problem really seems to be how parameters are parsed.

All right. It might not be that bad. I messed up with between --armor and -armor but they lead to different results:

Even more weirdness here. So on my test .gnupg directory I just removed the public key of the unwanted recipient.

I went ahead and modified my ~/.gnupg/gpg.conf to use the valid RSA2048 key I want to use for the recipient:

I need to look closer at some details. However it seems that because your default-key has no valid encryption key, --default-recipient-self tells gpg to encrypt to the first usable key in the keyring. This is clearly a bug.

Here is more details. One thing to notice is that the default key mentioned in my config files no longer has valid subkeys since they have all recently expired. I'm in a process of updating them but since I'm only encrypting (and not signing) for a different key I thouhgt it wouldn't be an issue.
I could just delete the offending pub key or clean up my pub keyring but I think it would be good to understand that issue in case there is a weird parsing error.

I've contacted Yubico to review this ticket.

Hi, that works as advertised. If this is the best solution yubikey permits us I am ok with it.

I put an entry: https://wiki.gnupg.org/SmartCard#Known_problem_of_Yubikey

After resume, because resume is not detected, some user interaction is required to cause an error.
gpg --card-status (which will only show partial information) is enough. Or, ssh failure. After failure, scdaemon reconnects the token.
Then, you can use it again without plug-off/plug-in.

Thanks a lot for pointers and suggestion.
Well, the problem of Yubikey itself cannot be solved by others, we can put some workaround for the error recovery.
So, this is another try of mine to improve error recovery.

• There was same problem in yubico-piv-tool and it was solved by detecting error state (0x80100068) and reconnecting to the smart card if necessary [1]
• There is also a thread in OpenSC discussing this issue [2] and relevant PRs [3]
• I also found a project that claims to fix SCARD_W_RESET_CARD by disabling exclusive access to the card before asking for PIN (and then they enable exclusive access again) [4]

Part of the problem is Yubikey side, I suppose. (Because my implementation of Gnuk Token has no problem for suspend/resume if it's in-use.)

Again, thanks a lot for your testing. The log said: The code I added cannot detect the event of suspend/resume.
It seems that there is no way to recover from suspend/resume for Yubikey.

Yeah, this is better, we got apdu_get_status => sw=0x0 status=7 and I can auth with this version as usual. After sleep-wake cycle it would however fail with pcsc_transmit failed: reset card (0x80100068). Logs attached.

Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)

Thanks, this version of scdaemon executes.

Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).

Probably you are right but I don't know Windows internals that much.

I wonder if this also works similar in a multi user system:

Fixed. But you need to wait at least 4 seconds even with a 2 seconds ttl. Will go in 2.2.6 in about 3 weeks. Thanks for reporting.

Well, if you have access to the user's memory you are lost anyway. Should be fixed, though.

@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.

If possible, please try with this (patched version of scdaemon):