- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
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).
thanks, @werner!
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
Fix that, thanks for your review.
I recently switched to a new input method program and lost my preference historys, resulting in these homophonic errors.
Notes to self:
- The function is called get_best_pubkey_byname (in g10/getkey.c).
- Recent changes:
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.
Feb 24 2021
Thanks for the fixes, @werner!
Can you please run
Hi, thanks I'll give it a spin tomorrow.
I think this is now ready for testing.
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:
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.
Thanks for the report. Frankly the curses pinentries are not that widely tested.
Sure
Any idea, what this could be? Misconfiguration from my side?
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:
Feb 22 2021
Released with gpg4win-3.1.15
The configure run tells you what libraries are missing - none in your case. However, something is wrong with your development setup: The configure run detected libksba but cc compiler did not found it anymore. Check that you don't have any special envvars set etc. What is the actual compiler command which failed (make sure not to pass V=0 to make for this).
Note that the backlog at https://dev.gnupg.org/tag/gpg23/ has quite some items and it is not yet clear which we will implement/fix first.
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
Dear Werner,
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 20 2021
Plesae run gpg with the option --verbose and put
Feb 19 2021
Hm, got something similar on macOS runner as well (however, in this case secret key is generated by RNP, and then successfully imported by GPG) :
2021-02-19T10:49:42.8239220Z /tmp/rnp-local-installs/gpg-install/bin/gpg --homedir /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/rnpctmp3ciohli5/.gpg --pinentry-mode=loopback --batch --yes --passphrase key2pass --trust-model always -o /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/rnpctmp3ciohli5/cleartext.dec -d /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/rnpctmp3ciohli5/cleartext.rnp 2021-02-19T10:49:42.8240980Z gpg: AES256.CFB encrypted session key 2021-02-19T10:49:42.8241480Z gpg: encrypted with 1 passphrase 2021-02-19T10:49:42.8242430Z gpg: encrypted with 1024-bit RSA key, ID 23295470BD33EA4A, created 2021-02-19 2021-02-19T10:49:42.8243090Z "key2@rnp" 2021-02-19T10:49:42.8243580Z gpg: public key decryption failed: Corrupted protection 2021-02-19T10:49:42.8244650Z gpg: encrypted with 1024-bit RSA key, ID 3A9FE68E283F7439, created 2021-02-19 2021-02-19T10:49:42.8245220Z "key1@rnp" 2021-02-19T10:49:42.8245690Z gpg: public key decryption failed: Bad passphrase 2021-02-19T10:49:42.8246250Z gpg: decryption failed: Bad session key
Attaching the full log:
Well, it's a (hard) requirement unless you explicitly disable efl, i.e. ./configure (without --disable-efl) fails with an error if elementary or ecore-x is not found.
I don't think the patch made elementary and ecore-x dev headers an absolute hard requirement; in particular, ./configure --disable-efl works fine to build pinentry without having these headers installed.
The following patch makes the efl requirements optional unless pinentry-efl is explicitly enabled:
diff --git a/configure.ac b/configure.ac index bc67c14..ce170c9 100644 --- a/configure.ac +++ b/configure.ac @@ -423,7 +423,24 @@ AC_ARG_ENABLE(pinentry-efl, pinentry_efl=$enableval, pinentry_efl=maybe)
rP19a18ba5fee0 makes elementary and ecore-x hard requirements for pinentry. I don't think that's intended.
For the pogo-pin test clip to flash, it is available in China.