Still, the first thing you should do is to update to a recent version, the version you are on is about 3 years old. See https://gpg4win.org for the most recent version. Then add --verbose and --debug ipc to your command so we can maybe see more what it does.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 4 2022
Jul 27 2022
I tried to reproduce this as we had similar problems in the past, but for me this works with full unicode characters.
Jul 26 2022
Jul 18 2022
as of 2.3.7 (which I just updated to) this works. ticket can be closed
Please give us more information.
- Do you change SSH program?
- If so, please check if adding configuration https://dev.gnupg.org/T5935#157674 for ssh works.
- Do you mean, reinstalling gpg 2.3.4 fixes your issue?
- Are you using with smartcard/token? Which one (Yubikey/Zeitcontrol/Gnuk), if it's the case?
Jul 13 2022
Reading through the report, the spec., and current implementation, I concluded that this is not a bug, thus, I'm closing this.
Jul 3 2022
@werner For what it's worth, I would like to apologize for my rudeness and disrespect. I had a quite convoluted notion of what the development process entailed. In particular, I was ignorant of the different and opposing responsibilities and the separation of concerns involved in the development process. In retrospect, there were at least a dozen different ways in which this could/should have been handled and all of them are downstream.
May 18 2022
Glad to hear. I've also now had time to manually apply the patches and have not seen any issues so far! Thank you! If anything does turn up later down the road I'll let you know.
No, no apologize needed. You did your best for the bug report, and it helped us a lot to identify the issue, and it certainly helped resulting the fixes. Moreover, your report kicked another fix of T5979 (thanks to the valgrind output).
Thank you.
May 17 2022
I apologize, you seem to be right. Even though the package build log shows that all patches were applied, it seems there are some hunks missing in the generated sources.
I've attached my patches, but those are most likely correct. There seems to be an issue with my distribution's package manager. I will investigate this and report back afterwards. Maybe I'll just build it manually.
When compiling the package, I can see that all 4 are applied.
May 16 2022
I think that it means that you only applied the last two patches.
Thanks again for your update.
May 13 2022
Thanks a lot for your cooperation.
I put more fix for error handling of key algorithm attribute.
The change: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.
Thanks a lot for your cooperation.
May 12 2022
Contrary to your expectations, all gpg --card-status fail after yubikey insertion:
Please do experiment again and give us the whole log of scdaemon.log for:
- insert Yubikey initially
- run gpg --card-status (success is expected)
- remove Yubikey
- insert Yubikey second time
- run gpg --card-status (failure is expected)
In case you need any information, be sure to let me know. Maybe we can add some manual loggers to the patches, to confirm that everything is working as you imagine it to?
Umm... The problem is the last bogus octet from Yubikey. In the log, we see:
May 11 2022
I'm certain I've applied the patches correctly. This is my current patchset:
Thank you for the logs. It seems that scdaemon didn't detect the removal correctly.
May 10 2022
I've uploaded the requested information with triple verbose and debug-all setting in the scdaemon.conf as scdaemon.log:
I examined all log files you gave us, and I think that scdaemon with PC/SC fails to detect the removal of the USB device.
May 9 2022
I've applied the linked patch, but still experience the error. Most of the times, I cannot access my yubikey at all and I am not sure what is blocking it.
I've tried to include as much debugging output as I could below. Please let me know if there is anything else I can do to debug this.
The patch rG054d14887ef8: scd: Add workaround for ECC attribute on Yubikey. fixes a particular problem of Yubikey implementation where it returns bogus octet for its data object of C1, C2, and C3.
Apr 27 2022
The issues mentioned in the previous comment have been fixed.
I had a look at the file system watcher we use to react on changes in the GnuPG home directory. It doesn't watch the private keys living in private-keys-v1.d. Moreover, it does not handle the removal of files properly.
Apr 14 2022
Mar 28 2022
When we will find reproducible test case, please reopen.
Mar 23 2022
Thank you.
Mar 22 2022
Mar 19 2022
{F3381469}I uploaded the whole homedir containing the keys after they were migrated by the new gnupg2.3.4. It should have all of the keys in there. Don't worry, these keys are just for testing and not used anywhere.
Mar 17 2022
Jan 10 2022
Oh, I' sorry - my fault. I searched in ...\GnuPG\bin instead of ...\gpg4win\bin
I have just checked both the installation script, which still installs gpgme-json.exe and the gpg4win-4 installer downloaded from gpg4win.org gpgme-json.exe is properly installed under <instdir>\bin gpgme-json.exe and under bin_64
Dec 6 2021
Hi guys, I just tested the git version (426d82fcf1c133bfc1d5c931109d71db3f3815a9) and it works well thank you.
Fixed in 2.2.33.
Nov 13 2021
Oct 27 2021
Sure there are logs, see the options log-file and debug in the man pages.
To sign using specific subkey or the main key, use the fingerprint of the key and append an exclamation mark.
For example
I think that this is due to support of UTF-8 codepage problem by console.
Oct 23 2021
Hello Mr. Koch,
Oct 22 2021
@Reiner: Any news; were you able to run the the command with redirection to some file?
Oct 20 2021
Lets downgrade the priority and keep it open in case we get reports from customers. The other option would be to replicate this here using our AD demo network. But that is a bit time consuming.
I tried to reproduce this. Experimentally, I added P15CardWidget::searchPGPFpr() to OpenPGPKeyCardWidget, commented out the code that checks for an LDAP keyserver and called the function with a fixed fingerprint.
Oct 15 2021
I don't know if it's same in your case, but to fix my case, I pushed a change rG48359c723206: dns: Make reading resolv.conf more robust.
I managed to create a case. Put a line:
BTW, in your screen shot (log is preferred here), it shows 1c00, that must be actually written as AAAA (0x1c). In the bug T3803, we saw byte sequence like that, additional 00 was added then resulted malformed DNS packet.
Oct 14 2021
dots are not allowed in hostnames.
OK, I'll gdb in there to see what happens. My domain is a classic pgp.domain.com
Ah, other possible case is .. in hostname.
Oct 10 2021
Problem/Bug still persists in current version (gpg4win 3.1.16) --> reopen
Oct 8 2021
Thanks for the log, however, I would suggest to use 3.1.16 and try again.
Oct 7 2021
And it shows
Thank you so much for your explanation.
I just want to try with older version. Because when I try to run
Oct 3 2021
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?
Sep 30 2021
Aug 27 2021
Aug 26 2021
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.
Aug 13 2021
Jul 7 2021
Jul 6 2021
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.
Jul 5 2021
Jun 26 2021
wk at gnupg dot org but better avoid any HTML parts etc.
Jun 25 2021
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.
Jun 19 2021
May 18 2021
I have the same message when i try to decrypt files larger than 1.5GB in size; i atached the report "gpgconf --show-version"
Apr 15 2021
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
Feb 25 2021
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
Feb 24 2021
Can you please run
Feb 23 2021
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.
Feb 22 2021
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?
Feb 21 2021
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.
Feb 9 2021
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.
Jan 27 2021
provided Info by comment from 20201003: please remove Tag "Info needed (Backlog)"!
Jan 5 2021
Please try gpg4win 3.1.14 and check whether your problem has gone.
Dec 26 2020
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
Dec 23 2020
Good. The error recovery worked well.