Hi, Werner.
My OS has everything compiled from sources obtained from devs as they release them. Funtoo Linux is a derivative of Gentoo Linux.
Hence, the default behavior of the software is not altered except when removed some of its features, but I've installed gnupg without alteration.

So the assumption is it is an Error of the GnuPG card.
I tried today with an Yubikey 4 and it works. This confirms the theorie.
However - my preference is on the Smartcards. So how would we proceed now. Who can check for the error and correct it / flash a new version on a card.
I would offer to verify if it is fixed.

This looks more like an Enigmail bug. In particular the manual start of gpg-agent as described in the workaround is useless because gpg-agent is always started as needed. I don't know your OS and thus I do not know whether gpg-agent is used in --supervised mode, as in Debian, or in the default way. What does

The first thing you should do is to write a proper bug reporting, including your OS, any special configiration you use (e.g. using a dedicated DNS sever) and the exact commands you give and outputs you see. Always use option -v with gpg. dirmngr can create a log file:

Despite that the use of a passphrase is entirely useless if a command like that is used, you need to add

--pinentry-mode=loopback

to the invocation. ( I assume you are using gnupg 2.1 or 2.2)

Andre, I assign this to you. If you don't think that a better warning in Kleopatra is needed, please close the report.

OK. Thank you for that.

Thanks for asking. We may need to put this into the FAQ, so here is my answer:

Forgive me if I'm completely off the mark here. In no way do I claim to fully understand gpg etc.

Here is an extract of the log file which shows the assumed cause

The last line shows that gpg decided that to return a failure because the message does not use the MDC scheme. Since the introduction of modern algorithms with a _blocklength_ of 128 bit (e.g. AES) gpg always uses the MDC encryption system even if it is not announced by the respective key flags. The reason for theses algorithms are newer than the MDC system and thus we can expect that all applications supporting AES will also support MDC.

Ignore my previous comment - seems that if I'm off our corporate network, I have the issue. Back on the network, Kleopatra is ok, and the gpg command completes. (I suspect that there is a firewall rule required, as the firewall is only enabled off network.)

OK. I managed to reproduce same behavior. I think that it is a bug of OpenPGP card implementation.
Here is the log:

Tried that, and it complained that the gpg-agent was not running. Now Kleopatra fails to , constantly trying to load certificate cache. Self test fails on UiServer Connectivity. Was fine up to that point.

I guess that the MDC indicated a broken encryption or no MDC was used at all. Can you pleae run the decryption of the file on the commandline? Assuming that thar the file is msg.eml you do:

I sent the gpg: DBG: DEK frame via encrypted eMail to you. Hope this helps.

FWIW, the old format was only used up to PGP 2.3 . PGP 2.6 used the new format. This is actually more indication that the message has not been generated by an old PGP version.

Could you please give me the debug output line for DEK frame: by encrypted mail to me? So far, I can't find any likely scenario where an error occurs with smartcard. (Use of PGP2.6 is unlikely.)

Agreed, Signing subkeys can be useful for checking historical signatures. And even encryption subkeys *can* be useful after their expiration, e.g. when doing historical auditing.

By the given version number, do you mean: with gpg4win 3.0.1 it worked with 3.0.2 id does not work anymore?

Please explain en detail what you are trying to do and what the error is. Thanks.

Running tests with a modified keybox, so that the the keybox has only the meta data and the actual keyblocks are stored in separate files improved --list-keys by a factor of 10. This can be explained by reducing the size of pubring.kbx (which is sequentially scanned) from 95 to 2.5 MIB.

I added "futuredefault" as an alias and also made the matching case-insensitiv. Changing the rendering is not easy because using a non-breaking hyphen in @code{} would not look very nice.

The conformance problem may (only) happen between PGP 2.6 and OpenPGPcard, because PGP 2.6 uses old format not compatible to PKCS#1, but OpenPGPcard requires PKCS#1.

that solved the problem, by updating libassuan

When i read the manpage, nroff-formatted against an 80-column terminal, it says, literally:

Enabled Logging, and here the results with some Errors inside...

It is

future-default

and not

futuredefault

Ok - thats good news.
Thank you very much for your analysis.

Any fix for this should be included in the test suite to avoid a regression :)

Using an external process as an option is fine. However adding more dependencies to gnupg should be avoided.

So… Is there any interest in the approach I drafted in D442?

I can see the case for encryption subkeys. Signing subkeys are still useful after their expiration.

OK, I got the picture, now.

Well, my speculation of SERIALNO undefined may be wrong.

Thanks, I received the log file.

If you are encountering the problem, please

1. Check that you have updated your Windows operation system to the latest version and you've got all security updates. (As some necessary certificates may have come later with an update.)
2. Does the behaviour change if you "investigate the certificate chain" through -> Properties -> Digital Signatures?

Thank you for your efforts. Logfiles is in the mail

We recieved another mail by a customer about this issue today:

Thanks a lot for your testing. Here are my keys:

All right - that was quicker.
I deinstalled pcscd (apt remove pcscd)
I changed .gnupg/scdaemon.conf as you proposed.
I tried again to decrypt the message (in the meantime I have a file) which works decrypting withoutl SmartCard when I use it on a pc with the key.
Still failed. Can I send you the Logfile encrypted ? If so - what is you eMail / key.

As said - it took me a while. Sorry for the delay.
I could dig out the Key in some archives. So I was able to test the decryption of the message on a computer without smartcard.
It worked.

Thanks for your report. This is because GnuPG 2.2.4 now requires newer libassuan (in order to fix a race condition).

Thanks a lot. I'm going to push the fix to 2.2 (and then master).
In short, it was the bug in ccid-driver of scdaemon, which was introduced last year when I enhanced it to support multiple card readers at once.

Yes, thank you, the smartcard is being recognized now.

Thanks (again). According to the status code (bStatus), the card reader said no card is available.
Could you please remove the card and re-insert it, and do 'gpg --card-status'?

After

patch -i scdaemon-fix-for-inactive-start.diff scd/ccid-driver.c

the following log obtains.

Thanks a lot for your testing. Please test this patch:

After installing libusb-devel, and configure and make, this is the new log.

Thanks. I think that you configured GnuPG without libusb, thus, ccid-driver is not enabled, and you don't have pcscd installed. In this situation, no way to access any smartcard reader.

Please enable all debug information in scdaemon.conf, like:

verbose
verbose
debug-level guru
debug-all
debug-ccid-driver
log-file /run/user/1000/scdaemon-verbose.log

The file scdaemon.log is short and contains only:

2017-12-24 12:32:53 scdaemon[4347] écoute sur la socket « /run/user/1000/gnupg/S.scdaemon »
2017-12-24 12:32:53 scdaemon[4347] gestionnaire pour le descripteur -1 démarré
2017-12-24 12:32:53 scdaemon[4347] pcsc_establish_context failed: no service (0x8010001d)

Thanks for your testing. please give me scdaemon.log with updated scdaemon.

With latestes master, there still appears:

--- ~ » gpg --card-status                                          2 ↵
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: selecting openpgp failed: Aucun périphérique de ce type
gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type