That is a problem on the macOS side, for example with their PINentry tool. Sorry, we can't help you here.
In any case we won't support a gpg4win version released nearly 4 years ago.
That it. Things works nicely for me. Won't be backported to 2.2 because this introduces minor changes in the behaviour.
So far -- unlike the previous patch -- this seem to help (but since the issues are infrequent I can't be entirely sure yet).
Thu, Mar 4
Ingo, as you are currently working on the config dialog, maybe you could also fix this issue on the way.
Wed, Mar 3
========= 0110.asc ========== # off=0 ctb=88 tag=2 hlen=2 plen=117 :signature packet: algo 22, keyid E267B052364F028D version 4, created 1614755507, md5len 0, sigclass 0x01 digest algo 10, begin of digest 4f 78 hashed subpkt 33 len 21 (issuer fpr v4 249CB3771750745D5CDD323CE267B052364F028D) hashed subpkt 2 len 4 (sig created 2021-03-03) subpkt 16 len 8 (issuer key ID E267B052364F028D) data: ADEE890B755C3B52D46FB0105097F23B5905B472C626222ACB4E441D8EB40001 data: 007119FF80C34DA152BDB07E1EF5D968CB9F2773002A0CF57911670BE248CF06 ========= 0354.asc ========== # off=0 ctb=88 tag=2 hlen=2 plen=117 :signature packet: algo 22, keyid E267B052364F028D version 4, created 1614755520, md5len 0, sigclass 0x01 digest algo 10, begin of digest 28 19 hashed subpkt 33 len 21 (issuer fpr v4 249CB3771750745D5CDD323CE267B052364F028D) hashed subpkt 2 len 4 (sig created 2021-03-03) subpkt 16 len 8 (issuer key ID E267B052364F028D) data: 001DB3839E3FD8D4CB81357EE5E42F4AF652C252A03A0FB21768621B1025C08C data: AF5A0910EF1D4D6BDD07EA0AA6D69049CB7BA7ED42427E14B8B72CF2C2231704
Here are example files produced by GnuPG 2.3-beta:
S part has preceding zero:
R part has preceding zero:
Tue, Mar 2
Mon, Mar 1
I said "we're offering the optional use of GPGME
At the time I started to add an optional binding from Thunderbird to GPGME, I wasn't aware of gpgme-json.
We could add compatibility mode for Ed25519 signature to confirm well-formed MPI (expecting recovery).
Thu, Feb 25
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
Okay, okay, I had in mind that we print them because we used to put such certificates into the ephemeral certificate storage because it is not possible to check the signature. But I reliazed that this changed quite some time ago and we can view these error messages as informative only. They are now not anymore printed int quiet mode. Well, for 2.3 - not sure whether I should backport this to 2.2.
Wed, Feb 24
Thanks for the fixes, @werner!
Can you please run
As suggested in the linked question on stackexchange, I think that even if the error comes from the pinentry program, GnuPG could echo a more informative error than gpg: decryption failed: No secret key, such as terminal to little to show the pinetnry program, or something similar.
Done in 2.2 and 2.3. The issuer certificate thing is a real error message and thus it should be printed.
Other ways that gpgsm --quiet is not quiet:
Tue, Feb 23
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.
Thanks for the report. Frankly the curses pinentries are not that widely tested.
Fixed in libgcrypt 1.9.2. Thanks!
Ingo, can you take care of this one?
With 2.2 the second works if the first passphrase prompt was canceled. Test invocation: