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.

Thanks for the info. So I guess me added that restrictions to be on the safe side regarding the VS-Nfd evaluation. For 1.9 we can and should lift that.

Please see [1] appendix F - I tested it more or less on all major CPUs, small
and large, old and new:

AFAIK, Stephan evaluated it only for x86, let me ask him ...

Done.

Thanks. I bumped it up to be in sync with GnuPG 2.2. It also does not make sense to require a Libgcrypt which has reached end-of-life; Thus we now need 1.8.

I bumped up the requirement to 1.25 because we also use error codes defined there. To be on the safe side with older distros I defined the missing error code instead of requiring 1.27.

Thanks for the report.
I now describe the shortcuts as development and 2.2 stable branch.

The problem is with the code for T3656

Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.

@Angel: The mail server log showed 0 bytes for the affected messages.

While triaging issues this looks to me more like a support case. And not an issue of the software itself. So I'm closing this issue.

As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.

Are they actually zero-byte mails, or is the content mungled as an attachment? (which those replying probably overlooked, and would still be hard to interpret, as it would containe MIME parts)

Although this is a standard behaviour for Unix tools, you are right that it makes sense to tell the user about the problems. And well, the version info should not appear either.

I observe the same problem since I installed gpg4win 3.1.11 (german) in Outlook, Office Professional Plus 2019, Version 2004: Occasionally "zero byte mails" are sent by replying to an s/mine certified and encrypted mail. In my case the option s/mine support is disabled in GpgOL menu.

Fixed in master and applied to 2.2 branch too.

Sorry, I was reading the next commit (libdns: Avoid using compound literals (3)).

I have to disagree. Unless I am completely confused the modified functions use automatic buffer variable and then basically return it.

Robin H. Johnson created a patch for this:

Possibly, it would be dns_p_init which was caught. If so, it's false positive; It returns a pointer given to the function (which is automatic variable of parent function), but it is valid within the scope of parent function.

Could you please show more information, a specific point of the bug?
I can't locate any place where a function returns a pointer to automatic buffer.

Seems to be fixed now.

Closing with Info Needed.