The Python bindings are troublesome enough; as of today we don't want to maintain a Perl module.

No info received in3 years.

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

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.

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.

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.