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:

You may start the gpg-agent by hand:

In T4978#135418, @werner wrote:

The 5 second timeout is to give the agent time to get ready and accept connections.

The problem is that I have not yet found a _portable_ way to detect proper working v6 or v4 networking without doing a test connection. For privacy reasons we don't want to do that.

The 5 second timeout is to give the agent time to get ready and accept connections. I can't say with this infor why it takes longer at your site. Can you please try without putty support?

That is unfortunately not possible because there is no fixed link between the key and the rev cert. Instead they are linked via cryptographic signatures. The pre-generated rev certs are a fail stop measure in the case that the user lost access to the private key and can't create a revocation with a concrete reasons etc.

Any news on this?

Thanks for explaining; this may indeed lead to a followup processing error of correct data. However, I don't expect to ever see a fixed length header of 2GiB or more because the sender would have had to buffer all that data in the first place.

Please describe the problem and don't just paste compiler output.

This appears to still be a problem, despite upgrading to libksba 1.4.0:

Cool, thanks for fixing this!

Argh, I had overlooked that you even mention a pull request.
So Apologies that I did not attribute the fix directly to you.

Thanks for the nice report. The fix was completely straightforward, I just didn't think about rich text when I implemented it.