No info received in3 years.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 16 2020
Has already been fixed with T4061.
C part done; C++ interface is not yet done.
Hi, yeah its complicated for Kleopatra to detect the defaults as they can be set both in Kleopatra config and GnuPG config. The GnuPG config overrides the Kleopatra config. Kleo has code to handle this but not when it adds the comboboxes to the GUI. So I've just removed the "default". We only had this for RSA and DSA / Elgamal, for ECC we did not indicate the default.
Well, it changes the behaviour on error and thus it should not be backported to 2.2 so that existsing error reports about corrupted data don't change. Fine for master.
Here are the fixes:
diff --git a/common/init.c b/common/init.c index 073c5cd8a..dbdf40527 100644 --- a/common/init.c +++ b/common/init.c @@ -161,17 +161,6 @@ _init_common_subsystems (gpg_err_source_t errsource, int *argcp, char ***argvp) /* Try to auto set the character set. */ set_native_charset (NULL);
Call of WSAStartup in dirmngr/http.c is no problem, as we define HTTP_NO_WSASTARTUP.
This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem
Today when I've been trying with -j48 test suite was locked and was not able to finish.
When I've presses ctrol-c I found:
PASS: t-eventloop Decrypt B 0 Encrypt A 0 Decrypt B 1 Encrypt A 1 Decrypt B 2 Encrypt A 2 Decrypt B 3 Encrypt A 3 Decrypt B 4 Decrypt B 5 Encrypt A 4 Decrypt B 6 Encrypt A 5 Decrypt B 7 Encrypt A 6 Decrypt B 8 Encrypt A 7 Decrypt B 9 Encrypt A 8 Decrypt B 10 Encrypt A 9 Decrypt B 11 Encrypt A 10 Decrypt B 12 Encrypt A 11 Decrypt B 13 Encrypt A 12 Decrypt B 14 Encrypt A 13 Decrypt B 15 Encrypt A 14 Decrypt B 16 Decrypt B 17 Encrypt A 15 Decrypt B 18 Encrypt A 16 Decrypt B 19 Encrypt A 17 Encrypt A 18 Encrypt A 19 PASS: t-thread1 make[4]: *** [Makefile:882: check-TESTS] Interrupt make[4]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/tests/gpg' [tkloczko@barrel SPECS]$ make[3]: *** [Makefile:1008: check-am] Interrupt make[2]: *** [Makefile:1010: check] Interrupt make[1]: *** [Makefile:736: check-recursive] Interrupt make: *** [Makefile:535: check-recursive] Interrupt ^C
+ GPGME_DEBUG=8:gpgme.trc + /usr/bin/make -O -j1 V=1 VERBOSE=1 check Making check in src make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/src' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/src' Making check in tests make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/tests' Making check in gpg make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/tests/gpg' /usr/bin/make check-am make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/tests/gpg' /usr/bin/make check-TESTS make[4]: Entering directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/tests/gpg' gpg-agent already running PASS: initial.test -----BEGIN PGP MESSAGE-----
Jul 15 2020
It might be related to T4257 - try with -j4 for now which is what I use for building.
For further investigations we need to enable tracing using
GPGME_DEBUG=8:gpgme.trc make check
In T4854#135871, @werner wrote:Sorry, I can't replicate this
Probably the same as T4257
We can't do anything about it except for corner cases which we won't do right now. In case there will be an easy solution to help Debian please re-open this bug.
Sorry, I can't replicate this
From 1.14.0 on these functions will return a Not Implemented error and the documentation has been removed.
I used already the mentioned blog ass base of my work. But the Yubikey is not recognized in ssh and I do not know how to mitigate.
Its a year since I worked on the mentioned wait code change (wk/new-wait branch) and I more or less forgot about it. it will to risky to release that as 1.14 so this change and the fix to this bug needs to be postponed to 1.15. Sorry.
A reference might help:
https://blogs.itemis.com/en/openpgp-on-the-job-part-8-ssh-with-openpgp-and-yubikey
@mbrinkers : I think that it was fixed in GnuPG 2.2.21 by T4908: ECDH with AES-128 decryption failure when fully padded.
It was unfortunate that this bug report didn't work to solve problem, with malformed data and discussion went to unrelated thing.
Jul 14 2020
Thank you very much for working on this issue.
I think there might be a problem with your fix, if there is a mail arriving with
more than 1 attachment with invalid filenames. I expect all but the last
processed attachment with invalid filename will be overriden by this fix. I
think this will happen very rarely but maybe it is worth consider this also.
Of course I may be totally wrong with my thoughts as I'm not a programmer and
don't know how gpgol is handling attachments in mails.
kind regards
Helmut Häfner
I have run into an interoperability issue between BouncyCastle PGP (Java) library and gpg which seems to caused by key obfuscation.
I have also relaxed the test in gpgme for that GnuPG version.
I can reproduce the issue. GpgOL creates a temporary file using the original filename and that fails because the pipe is one of the invalid filename characters on Windows / NTFS.
After digging through our complete parser code it turns out that we did everything correctly but Outlook adds the line break when we change the bodyformat from HTML to plain text. So this issue only existed since the fix for: T4639
Great! That fixes it. Many thanks!
Dear Werner!
Dear Werner!
See T4897 for a patch to gnupg.
It turns out that a test case in GPGME fails with that version. This is due to a regression I introduced in the passphrase repetition code for symmetric encryption. This will be fixed with the next GnuPG version; in the meantime you may use the patch F1646254.
Sorry, my fault. I found this command line in the internet (I am relatively new) so I mixed it up. Ok, skip ssh-add, it was my mistake! But the problem is that my Yubikey is not recognized by PuTTY in an ordinary ssh session. In the cmd window and in Cleopatra it works, but not with PuTTY.
So, where does "ssh-add" command come from? IIUC, it is from OpenSSH.
No, you are wrong, I speak not about OpenSSH!!! I speak from PuTTY. As explained in my first message, if I copy my ssh key on an USB stick and if I use PuTTY in combination with this stick, it is fine, I can connect to my server. If want to use my Yubikey 5NFC in combination with PuTTY, ssh authentication fail!
You mean running OpenSSH (and its tool ssh-add) on Windows, right?
It is not supported. PuTTY is supported.
Jul 13 2020
Yes :-). I see it also in line rows (many '_' characters). As I wrote, I (and probably all others) always exptected this to be a formatting error on the sender's side :-).
It's not only for URL's. I've tested with any long line when sending "text/plain" GpgOL properly sends this but displays it wrongly.
It is a pecularity of the test case. A new release is long overdue anyway, so please have a few days patience for a new release with a foxed test case.
To change the expiration date, I would suggest to use
- compressed representation of EC point can be used in:
- public key
- (exporting) private key
- signature
- ECDH ephemeral key
- Accepting compressed representation,for the initial implementation, I'd like to limit our effort for curves of NIST and Brainpool, except NIST P-224, which p = 3 mod 4.
Pushed fix to master and STABLE-BRANCH-2-2.
Thanks for your log.
Jul 12 2020
Jul 11 2020
$ cat /run/user/1000/dirmngr.log
2020-07-11 19:33:44 dirmngr[2305.0] permanently loaded certificates: 140 2020-07-11 19:33:44 dirmngr[2305.0] runtime cached certificates: 0 2020-07-11 19:33:44 dirmngr[2305.0] trusted certificates: 140 (139,0,0,1) 2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id CE04B58CBA5B8069AA0D503634B861593BE86F20; update required 2020-07-11 19:39:24 dirmngr[2305.6] number of system provided CAs: 148 2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] error connecting to 'http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl': Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] error retrieving 'http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl': Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] crl_fetch via DP failed: Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] command 'ISVALID' failed: Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id 3476EB7C1E02B3BAF954EEE2EFD321F7B8E49D18; update required 2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] error connecting to 'http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl': Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] error retrieving 'http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl': Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] crl_fetch via DP failed: Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] command 'ISVALID' failed: Address family not supported by protocol 2020-07-11 19:39:24 dirmngr[2305.6] force-crl-refresh active for issuer id 70F42DB9235EC84DC35D445B3407CABF4324291C; update required 2020-07-11 19:39:24 dirmngr[2305.6] error creating socket: Address family not supported by protocol