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
• 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.

Last week:

• Kleopatra 3.1.12 and some minor work on it.
• Some minor work on GpgOL
• Mostly buissness development again.

Right, I think that forcing v5 for ed448 makes a lot of sense.

Topics:

• I'd like to backport T4843: REGEXP support for all systems into 2.2

Last week:

• Bug fixes
  • T4246: GnuPG master does not allow decryption with bad usage flags (regression)
  • T4688: `make distcheck` fails trying to make `rst/gpgme-python-howto.rst`
  • T4977: dirmngr not working with linux kernel parameter ipv6.disable=1
    • backported to 2.2

This week:

Pushed fix to master and STABLE-BRANCH-2-2.

Thanks for your log.

$ 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

@gniibe I saw that you didn't understand what I meant by "dirmngr stops working properly" in E663.
Have a look at this post in Archlinux forum.

Yes, I forgot to include the full build log, I'm attaching it here. I've seen this in OpenSUSE Tumbleweed; the compiler is gcc10; and I can see this on any architecture. The test fails when building against gpg-2.2.21 but not with previous versions.

Pretty please write a useful bug report; we need information on versions, OSes, compilers, any special environment, and all the steps you did to get the build failure. The configure run already prints a lot of useful information; you may want to extract them or provide a complete build log.

Creating is not that useful - we prefer modern curves anyway.

I think that retrieving a parameter in compressed format is all what we need as per API.

(3) _gcry_ecc_os2ec in libgcrypt/mpi/ec.c should be modified to support parsing compressed representation.

While I see that it's not the matter of actual use case (but how gpg can be immune to fuzzing), code clean up would be good here.

Thanks for the patch.
I see your point in T4975: undefined-shift in block_filter.
You are right that we have a problem of possible overflow (which could be kicked by fuzzing) here.
(The actual impact would be small, though).

What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c for subjectKeyIdentifier, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.

Because a few minutes don't matter. If you have the time to figure the reason out, please go ahead. It might be that we take the timestamp in the addkey case earlier and only set the expiration date after the key has been created.

gpg has code to make sure that a new key is at least one second newer than the previous generated.

The default for GnuPG 2.2 is still 2048 (Debian changed that in their distributed version). The reason for this is that we don't want to generate such keys but move on to Curve25519 for the new defaults.