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.

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

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.

A reference might help:
https://blogs.itemis.com/en/openpgp-on-the-job-part-8-ssh-with-openpgp-and-yubikey

I have also relaxed the test in gpgme for that GnuPG version.

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!

See T4897 for a patch to gnupg.

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.

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.

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.

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.

I won't fix it. In fact it can't anyway be completely fixed because gpg has code to make sure that a new key is at least one second newer than the previous generated.

The first, I guess. The problem is that you are technical capable of _decryption_ but gpg does not allow this because for some reasons the key is arbitrary limited to signing. A warning message should be printed in thus a case but decryption should succeed.

Or this (don't allow anon keys for different usage):

diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c
index 14cbdbb0f..b8d4059cd 100644
--- a/g10/pubkey-enc.c
+++ b/g10/pubkey-enc.c
@@ -91,9 +91,6 @@ get_session_key (ctrl_t ctrl, struct pubkey_enc_list *list, DEK *dek)
       if (err)
         break;

Do you mean something like this?

Fixed in rM1b840a151ad7: python: Fix how to generate documentation..

Yes please.

Fixed; In master the code already uses our generic scheme parser.

Thanks,
I edited the task and now you can edit it too.

Hi,
could you please change the edit policy back to all users so that I can change the status of this task?

I don't think this fix has made it into a release yet. Could we get a released version of gpgme that contains this fix?

Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.

on #debian-dpkg on IRC, Guillem Jover suggested that we might want to fix dpkg specfiles to use +self_spec: instead of *self_spec:.

I think this might be the issue with High DPI support problems. T4819 which is not yet released.

Some information of Qt5 about -fpic:

• https://lists.qt-project.org/pipermail/development/2015-May/021557.html
• https://bugzilla.redhat.com/show_bug.cgi?id=1700435

Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400

Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.

I'm still not understanding what specifically should be fixed here. Sorry to be dense about it, but the range of options and configuration details that are different are pretty puzzling.

I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.

Thanks for your report.

Ok. This was just something that I noticed while going through configure.ac. Should I make patch for this or do you want to?

@dkg while I agree with your aim of

I have the same issue, it worked (I use Kleopatra for a long time), but last week, as usually, I tried to use Kleoptra to encrypt directly, I choose the file and nothing happen (no new windows, nothing at all...)

I don't know about macOS but the commonly used GNU tools state:

In T4980#135456, @werner wrote:

What do you mean by grep_options?

When I test it on Debian, disabling by,

Please get log of dirmngr, by putting

log-file /run/user/<YOURNUMBER-LIKE-1000>/dirmngr.log

Can you characterize the failure when ipv6.disable=1 ? The straightforward failure (connect() fails with EHOSTUNREACH after a few seconds) should presumably be treated the same as if some other host happened to be offline. That should result in dirmngr failing over to the next available address for the configured keyserver, right?

I agree with you that a certificate with a lengthy expiration is not cryptographically sensible or wise, @bernhard -- i'd never want to produce such a certificate myself.

Just added a comment to T4826 how to move forward, if this is still interesting for parties. Right now (from my point of view) a pubkey with an expiration date beyond 2106 is not a sensible key configuration, so the use to motivate a chance in this area would need to be argumented better.

This issue, as well as T4766 has the challenge that there is a disagreement about the usefulness of the use case, as far as I can see.

What do you mean by grep_options?

estream_t does not necessary work with stdio or posix calls; that is an implementation detail. For example if you use the mode flag "nonblock" Read/WriteFile are used on Windows.

I think the feature is not (yet) supported on Windows.
Please see: T3883: Add Win32-OpenSSH support to gpg-agent's ssh-agent

While the initial agent hang problem might be rare, it nevertheless does make sense to have a workaround for this in any case. Especially since it may not be possible to patch this effect away. The commands given by Werner provide this workaround nicely if gpg-connect-agent hangs.

These are very nice commands which I had overlooked. My results: