Thus better add a

&& !defined(__clang__)

Sure that the FreeBSD compiler does not define it? I am pretty sure it does.

According to list of attributes in the clang 12 documention, there is no such attribute in clang. However, the clang-11 compiler (as seen in Debian) does not define __GNUC__, so the proposed patch does not affect the status when building with clang.

You may want to check that clang supports this attribute as well.

Build Result:

In T5214#140791, @werner wrote:

For directories this can't be done because not only the server reads the directories but also other deployment tools (e.g. rsync).

I fixed the latter two points. For directories this can't be done because not only the server reads the directories but also other deployment tools (e.g. rsync).

I removed gnupg from the %AppData% directory and restarted Kleopatra, but I am running into the same permissions issue.

please move away %AppData%\gnupg
it usually expands to c:\users\yourusername\AppData\Roaming\gnupg

Screenshots of the issue are attached.

Please report about released versions. If you have problems building from Git, posting to gnupg-devel is the best way forward,.

The patch will be in 2.2.27. Thanks.

Simply add -v or --verbose to the gpg invocation too see infos about the pinentry. --debug-level is not helpful here.
And well, we don't have a way to test stuff on Vista anymore. You should also update to at least Windows 7.

Good catch. This is due to back porting a change from master. However the extra introduced conditional of

if (sig->version >=4)

will always evaluate to true. It is set a bit above and GnuPG does not handle public key packets with version 3 anymore. So this if can actually be removed. Thus no harm.

Please provide detailed information about the build peoblem. An arbitrary paste from a build does not make up a bug report. If you need support building GnuPG you may want to look for a commercial offer or to ask on a mailing list. From what I see I assume you have an incomplete installation of the supporting libraries.

Already have set another, thanks gnibe! See ya!

Please change your passphrase for your card, BTW.

Good. The error recovery worked well.

Thanks for reporting this. You are correct, those HWCAP2_SHA1 and HWCAP2_SHA2 defines are wrong.

Thanks, appreciated.

You are lucky. The report came just in time for the 2.2.26 released. Not mentioned over thre but anyway fixed. See T5153

This is x86_64 (amd64) Fedora Linux version 32 (nothing to do with the x32 sorta-architecture).

Oh well, sshfs.

Just for reference what OS and file system is this? It looks like some x32 Linux.

GnuPG uses the systems locale.

Thank you for your testing.
May I ask more test, please?

Hi, I have applied both patch and appears Yubikey is now working correct. I have uploaded the log here.

Werner, please retest. If "Change Reset Code" still doesn't work for you, then please answer the questions in the first comment.

Note: Officially, Kleopatra does not support OpenPGP v1 cards. At least, according to the text that is displayed if no card is found.

"Change Reset Code" should work in Kleopatra. At least for OpenPGP v2+ cards. Kleopatra simply does "SCD PASSWD --reset OPENPGP.2", i.e. the same as gpg-card. I have verified that it works with a Yubikey.

For support please use one of the community resources (see gpg4win.org) and read the manula (compedium) or one of the hundreds of HOWTO floating in the net.

In T5167#140229, @gbschenkel wrote:

Nice, I gonna apply the patch and see if resolves for me!

Nice, I gonna apply the patch and see if resolves for me!

You're right. Thank you.

Oh, any chance GPG could inform the user when using export-pka that it is dead/deprecated? Also thanks for the quick reply.

PKA is dead but anyway: What you see is a record from a DNS zone file which has a specific semantic. The 14 for example means that 20 bytes follow.

Nope, of course SNI is used. You problem is a different one. For example no root certificate, a server configured to allow only TLS 1.3, or a not supported algorithm. Decent versions of GnuPG print some hints if run with -v. BTW, an easier way to test is to use "gpg --locate-external-key" which basically does the same you did.

With my Yubikey NEO, when I use OTP (touching the button to generate OTP output as key input), I observed "card eject" event:

2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: interrupt callback 0 (2)
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: NotifySlotChange: 02
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: card removed
2020-12-10 11:23:05 scdaemon[7254] DBG: enter: apdu_get_status: slot=0 hang=0
2020-12-10 11:23:05 scdaemon[7254] DBG: leave: apdu_get_status => sw=0x1000c status=0
2020-12-10 11:23:05 scdaemon[7254] DBG: Removal of a card: 0

I have reproduced the bug

A backtrace with gdb from migw-w64 results in

I did a fresh install of Gpg4win 3.1.14 and imported my standard pubkey, by using

gpg --locate-key bernhard@intevation.de

on the command line.

Sorry, I can' reproduce thus. What kind of key is causing the crash?

I checked the development log for the addition of:

libusb_clear_halt (handle->idev, handle->ep_intr);

In T5167#139966, @gbschenkel wrote:

I have another yubikey neo but its clean. Can it help it?

I have another yubikey neo but its clean. Can it help it?

In T5167#139964, @gbschenkel wrote:

Changing modes will I lose/change my OTP and FIDO codes?

Changing modes will I lose/change my OTP and FIDO codes?

I would add "Provide a verbose message of why the key cannot be imported".

Following device (a bit older than yours, I guess) works well:

DBG: ccid-driver: idVendor: 1050  idProduct: 0112  bcdDevice: 0334

When I configure it to OTP+FIDO+CCID, it also works for me, it is:

DBG: ccid-driver: idVendor: 1050  idProduct: 0116  bcdDevice: 0334

Thanks a lot.
Let me explain the situation.

Although the output of --list-packets should not be parsed and is subject to change with each versions we know that ppl do it anyway and things start to break.

Sorry, no. Although the output of --list-packets should not be parsed and is subject to change with each versions we know that ppl do it anyway and things start to break. Even when we added lines starting with the usual comment sign (#) to indicate the offset of the packet, we received quite some bug reports. Thus such chnages will only be done when they are really needed. For all other the rule is still: Use the source, Luke.

Hi, I changed the PIN, killed the gpg-agent and scdaemon, edited the scdaemon.conf to include your instruction, after, I run the following commands:

Thank you for the information.
In the log, the driver detects removal of card wrongly.
That's the cause of this problem.

In T5167#139880, @gniibe wrote:

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Backported.

There is no caching for smardcard PINs. Once a key (or group of keys) on a hard has been used (i.e. PIN entered). that key can be used as long as the card has not been reset or powered-down. No rule without exception: Some cards may require that a PIN entry is required for each crypto operation. For example the OpenPGP card (which is implemented on a Yubikey) does this for the signing key but not for the authentication (ssh) key. To disable this for the signing key you use the "forcesig" command of gpg --card-edit.

OK, then we'll have to live with --disable-asm until the next major version is released, or switch to gcc.