Thanks. I added the OIDs and the missing curves. To go into 1.9

Okay. Now since configure.ac is already touching CFLAGS, it seemed like a good place to add that additional option here. All this is guarded by a test for GCC, and since clang mimics that behaviour, it works for them as well.

Take care: gpg is also used on platforms with proprietary compilers which don't support -f options. Thus you need to limit this to gcc.

After some more checking: LLVM-11 introduced the same behaviour in that regard, but appearently not a pragma/attribute to override this: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html

This works now with 0c1bd9076958e584820fadf997ca7d8a248b6888 but needs more testing before this can be relased. It will probably be part of a Gpg4win-4 beta.

I'd suggest to first try the current version to see whether the bug has been solved.

Please try gpg4win 3.1.14 and check whether your problem has gone.

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".