Hey, are there any other logs that I can grab? Is there a way to override the defaults, which will allow me to use the right key to sign?

Im using Windows 11
Before the restore, he are working fine
Im trying to sign a file
The kleopatra dont show more error info

We need a more detailed bug report to evaluate your problem. Please tell us your Windows version, any special software installed on the system (if any), a step by step description how to reproduce the bug, and any other information which can help us.

In agent_write_private_key of agent/findkey.c, when file is available, it returns GPG_ERR_EEXIST error. Thus, private (stub) key will be kept.

wk at gnupg dot org but better avoid any HTML parts etc.

Thank you, this is my great honor!
If it is convenient, can you provide an email address? So that I can elaborate to you.

Thanks. I added it to the list. If you have not yet done this I would suggest to write a note to gnupg-users.

I have the same message when i try to decrypt files larger than 1.5GB in size; i atached the report "gpgconf --show-version"

Please tell us more details on how we can replicate your problem. Which Windows version, any non-standard software installed, non-standard installation direcories etc. You may also provide the output of

Thanks for the information!
We'll update our CI.

MSYS builds are not supported. All kind of stuff may go wrong. Just don't use it. Please use the standard installer as listed at gnupg.org or install gpg4win (which includes this installer).

Sure, here is output:

2021-02-24T20:19:46.8671882Z + gpgconf --show-versions
2021-02-24T20:19:49.6868215Z * GnuPG 2.2.25-unknown (0000000)
2021-02-24T20:19:49.6871468Z MSYS
2021-02-24T20:19:49.6888515Z 
2021-02-24T20:19:49.6889344Z * Libgcrypt 1.8.7 (baacfb40)
2021-02-24T20:19:49.6889956Z version:1.8.7:10807:1.39-unknown:12700:
2021-02-24T20:19:49.6890454Z cc:90300:gcc:9.3.0:
2021-02-24T20:19:49.6891633Z ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:
2021-02-24T20:19:49.6892539Z pubkeys:dsa:elgamal:rsa:ecc:
2021-02-24T20:19:49.6893424Z digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:
2021-02-24T20:19:49.6894177Z rnd-mod:linux:
2021-02-24T20:19:49.6894666Z cpu-arch:x86:
2021-02-24T20:19:49.6895791Z mpi-asm:generic/mpih-add1.c:generic/mpih-sub1.c:generic/mpih-mul1.c:generic/mpih-mul2.c:generic/mpih-mul3.c:generic/mpih-lshift.c:generic/mpih-rshift.c:
2021-02-24T20:19:49.6897734Z hwflist:intel-cpu:intel-fast-shld:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc:
2021-02-24T20:19:49.6898968Z fips-mode:n:n:
2021-02-24T20:19:49.6899492Z rng-type:standard:1:2010000:1:
2021-02-24T20:19:49.6899888Z 
2021-02-24T20:19:49.6900359Z * GpgRT 1.41-unknown (0000000)
2021-02-24T20:19:49.6900739Z 
2021-02-24T20:19:49.6901208Z * Libassuan 2.5.4-unknown (0000000)
2021-02-24T20:19:49.6901605Z 
2021-02-24T20:19:49.6902048Z * KSBA 1.4.0-unknown (?)
2021-02-24T20:19:49.6902420Z 
2021-02-24T20:19:49.6902843Z * GNUTLS 3.6.15

Can you please run

Hi Werner,
Thanks for the reply. Will try to reproduce this and get back to you. Our CI wasn't have an option to upload artifacts in case of failure.

Released with gpg4win-3.1.15

In T5286#143493, @shaoyj wrote:

Excuse me, where is the link to this blog you mentioned?

@bobwxc wrote:
And I found a blog seems written by the SM2 implementation author of libgcrybt -- Tianjia Zhang. He/She drew a red circle on a standard picture of the Z_A.

Excuse me, where is the link to this blog you mentioned?

In T5286#142947, @werner wrote:

We need more information on the why and when of this change. We don't want to maintain different versions of the same algorithm. The I-D expired more than 6 years ago and thus it should not be used as a reference.

We need more information on the why and when of this change. We don't want to maintain different versions of the same algorithm. The I-D expired more than 6 years ago and thus it should not be used as a reference.

provided Info by comment from 20201003: please remove Tag "Info needed (Backlog)"!

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

GnuPG requires some C99 features - thus a language level of C89 might not work. We use variadic macros and the func macro. For details see doc/HACKING.

OS:AIX , Compiler: XLC

Good. The error recovery worked well.

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.

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!

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 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?

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.

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?

I could find no issue with the error handling for verify errors.

In T5159#139739, @werner wrote:

Put

extern char **environ;

after the the include directives.

Put

extern char **environ;

after the the include directives.

After applying @gniibe 's patch:

The problem is that posix_spawn is not portable enough for libgcrypt. It is really time that we move the spawn functions from gnupg to gpgrt so that we can use them also in Libgcrypt.

BTW, I'm not sure if the claim in T5009#136688 is correct.

See also: https://dev.gnupg.org/T5009#136688

See my comment in: https://dev.gnupg.org/T5024#139701

After disabling SIP, now all checks pass without having the library symlinked to /usr/local/lib. So it might be T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error after all.

After doing:

IIUC, for the build of Homebrew, it is the issue of in: https://github.com/Homebrew/homebrew-core/commit/e7da1e2157b2e8373c3b39ea6398f51588ea537c

No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.

Please use shorter password.
For gpgsm, maximum is 31 chars.

Did you remove .gnupg entirely? Secret keys are stored in .gnupg/private-keys-v1.d. If it remained, you didn't import your secret keys.
If it was the case, I'd like to merge this report to T3391: cannot import subkey that was once marked to be on a card.

Hello Werner,

Hmm. Now, even with a fresh session, dirmngr, GNUPGHOME not set, etc. it seems to work. It correctly uses the config file and the keyserver, and the logs show the Home and Config variables are set and communicated correctly.

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.

Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.

on #debian-dpkg on IRC, Guillem Jover suggested that we might want to fix dpkg specfiles to use +self_spec: instead of *self_spec:.

Some information of Qt5 about -fpic:

• https://lists.qt-project.org/pipermail/development/2015-May/021557.html
• https://bugzilla.redhat.com/show_bug.cgi?id=1700435

Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400

Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.

I'm still not understanding what specifically should be fixed here. Sorry to be dense about it, but the range of options and configuration details that are different are pretty puzzling.

I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.

Thanks for your report.

Parsing and creating of certs does now work. I was not able to find sample CMS objects so this part is not yet finished.

Closing with Info Needed.

hello
thanks for the feedback
it s indeed exchange 2007 (migration planned on long term)
we will try the imap workaround

There was a similar Problem in the past reported on our mailing list:

PS I forgot to say why movement to cmake will be the best way.

I totally disagree.

Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README

Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?