- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 21 2021
@alexnadtoka, did you do what Werner wrote in T5639#150626?
Recently, I have encountered many problems in adapting the graphical interface interaction between Yubikey and gnupg. I am thinking about why some settings need to be manually added to some additional settings. I found that there are many such solutions on the Internet. Is there any way that scdaemon can automatically recognize these situations and add appropriate settings.
Things are not that easy. I actually introduced a bug in 2.3.4. Here is a comment from my working copy:
@werner Thank you for the answer. Please advise mailing list address.
For support please use the mailing list and not the bug tracker.
Seen. @jukivili can you please add it to the AUTHORS file?
GNUpg version 2.3.4 was installed but did not help
Is there a way to ignore SSL check during connection? This might work. We have internal server for our users only.
Guys I am facing similar issue but my Lets ecnrypt certificates are all ok. What is the problem with my gpg4win client? When connecting to openpgp server it says certificate is expired. Anybody can help me?
Dec 20 2021
We can even remove the hexfingerrprint call. Will go into 2.3.4. Thanks.
It would be easier to educate gpgme about the 11.
So, this is the patch. Note that this is for master.
diff --git a/g10/keygen.c b/g10/keygen.c index 7f15027a2..a452ab6d6 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -5619,7 +5619,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, pk = find_kbnode (pub_root, PKT_PUBLIC_KEY)->pkt->pkt.public_key;
Actually, the "11" at the end of the "ERROR" status line means "bad passphrase". But I think gpgme ignores this status line.
Okay. gpgsm even logs "gpgsm: possibly bad passphrase given" internally.
Because, as a user, what do you do if you see "invalid object" you think that something is wrong with your data instead of trying to type the passphrase again.
As I understand it after the p12 decryption the output is just tried to be imported. With the wrong passphrase this is just garbage and can lead to different errors.
gpgsm 2.3.4 sends the result:
S ERROR import.parsep12 11 S IMPORT_RES 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ERR 50331713 Invalid object <GpgSM>
With Kleopatra 3.1.20.220370+git20211216T120053~68b4545e (22.03.70) using GnuPG 2.3.4-beta24 and Libgcrypt 1.9.4-beta152 I get the error message Invalid object when I import only berta-enc.p12 and enter a wrong password. I'll have to check with GnuPG 2.2.33.
I've uploaded my testcerts to: https://heinecke.or.at/div/testzertifikate.tar.gz.gpg
That KeyListJob returns keys which have fingerprint NULL is caused by keyservers returning just key IDs instead of fingerprints. The change for T5741: dirmngr does not ask keyservers for fingerprints should fix this. Still keyservers are only guaranteed to return key IDs, so we cannot assume that keys returned by KeyListJob have fingerprints.
The use of register_trusted_key in do_generate_keypair was a dirty hack utilizing a bug in --trusted-key ; it would be better to set the key as ultimately trusted.
I think that the change for T5685 introduced the issue.
Dec 19 2021
Okay, sorry. In the first two cases (encryption), GnuPG 2.2.33 generates
[GNUPG:] INV_RECP 10 F3C987C36C5C6343C9A5D5A1A3F494F6028E4866 [GNUPG:] FAILURE encrypt 53 gpg: [stdin]: encryption failed: Unusable public key
and exits with error code 2, whereas 2.2.32 doesn't display these messages and exits with return code 0.
Please be so kind and describe the regressions you see. 3 log files from your software are not very helpful.
Dec 18 2021
ikloecker: Please go ahead
Dec 17 2021
IIRC, the problem is/was that this breaks some old keyservers. But there are no more old keyservers - if there are useful keyservers at all.
Thanks!
I will study it soon.
GnuPG needs to be fixed. Done by rGe08225030dfb: w32: Prepare for the case gcrypt.h will not include winsock2.h..
Thank you for comments on random/rndlinux.c.
Pushed another patch to clarify the semantics of --enable-random-daemon;
It's only for building gcryptrnd and the test program getrandom.
Good catch. I pushed the change to remove use of random daemon remained.
Thank you for your quick testing.
The patch worked, thank you very much.
Dec 16 2021
Thank you. Tested locally that it does what it is supposed to do and all tests passed for me as expected.
Proposed patch:
@werner: thanks, with the 'pcsc-shared' option it works for me (after sending SIGHUP to scdaemon, of course). So, do I understand correctly that this cannot be the default?
Reading through the changes, the content and usage of the getentropy looks good.
the random daemon is still part of the configure.ac and the undefined _gcry_daemon_initialize_basics() and _gcry_daemon_randomize() is still used under the USE_RANDOM_DAEMON guard in several places. I think at least the following cases should be removed too (or the configure check to be modified to throw error or warning):