See T6310 and the release note update at T6303.

Sorry, you need to wait for gnupg 2.3.8. It's next on our shortlist.

Should be fixed.

The patch for T5834 (https://dev.gnupg.org/rMad3aabdd8a64156c7e3a75d695ae1ab2c4bec841) was already applied to the build of GPGME 1.17.0 for Focal, as I did browse the list of latest GPGME bugs first before reporting this bug. Attempting to build with the latest GPGME 1.17.1 (with the included ABI patch) results in exactly the same FTBFS for i386 only, so this does appear to be a distinct issue not related to that of ABI backwards compatibility.

Please see T5834 which is fixed in 1.17.1

Please see T5587

to explain a bit more: This report was opened after the reported defect was already fixed.
As we are getting many reports and technical suggestions, please keep the reports focused on one point only if possible
and open general discussion points about development improvements on gnupg-devel@.

For what it is worth we have also just tasked someone from our team to reinstate our buildbot / CI but this would likely not have helped in the current case of the libgcrypt buffer error as only ASAN with large hashtests would have found this. Still we have the general infrastructure for such tests we are just lacking resources. That is why we publish everything and encourage the community to at least help us with testing.

the issue regarding this self test was immediately found after release. Our development is completely open and everyone is free to run tests with our software on any platform at any time. We would respect and fix all those bug reports. None about this reached us during the development phase.
As this is not happening as it should during development we release and test on our platforms and build systems. When after the release others test, too we immediately fix the issues as happened with 1.9.1 in libgcrypt.

@hanno, this is a bug tracker and not yet another media for your rants.

See the release info over at T5052 which notes the problem. See T5140 for details and update to 2.2.25.

It has been fixed in the repo for nearly a year, see T4459. A new release is urgently required and will follow in the next days. I close this as a duplicate.

In T1287#94619, @werner wrote:

2.1 has the option --unwrap to just this.

We fixed this bug already in the repo. See T4459.

You are right. I originally left it open because it was in a different language but the first report. But it's cleaner to close it as a duplicate, also.

T4129 is also a duplicate.

Thanks for the report. This was already reported andf fixed. We are aiming for a new Gpg4win / GpgOL Bugfix release soon to address this and other regressions.

Dear Andre , all , T4020 does not even well-define the symptom and I
do not agree T4020 is a duplicate of T4079 . I'd close T4020 in favor
of T4079 . Many thanks . Mirko

Hi Mirko,

Good news! :)

Just as a note as you were the first to report this: I've finally found a solution. In the next version it will be possible to move around crypto mails. Hopefully your wife can then use GpgOL :-)

I'm closing this as a duplicate of T3459

I'm closing this as duplicate of T3459

Thanks for your report, but as JJworx already said this is sadly one of the known issues to which we don't yet have a good idea how to fix it. In T3459 there is an animation what is meant by "unselecting" the mails.

Hi Carlos,

Yes sorry, I decided against a release specially for that is it is not super critical, no data loss.

Ok, thanks!

Sadly this is a known problem, the workaround is to unselect the mail and then move / modify it through the right click menu.

Many thanks! This bug is fixed in Gpg4win 3.0.1.

Thanks for the efforts. I will subscribe there to be up to date :-)

Oops I just noticed that this was already reported in T3424 which I somehow overlooked. Let's handle it there as there are more subscribers in that report and it's older.

To keep the tracker clean I'm closing this as a duplicate of T3476 since both problems are very much related. GpgEx would print Internal Error if Kleopatra crashes or behaves unexpectedly.

I'm closing this as a duplicate of T3459 even if this bug is older we used it to discuss side topics.

Hi,
thanks for your report. We already have this on our todo with high priority: T3514
I'm resolving this report as a duplicate.

Then this is a duplicate of T3442 as well! Thank you for you Logfiles and your report!

Duplicate of T3441.

I am sorry, Kai. I am afraid I can't close this bug.

I close this one. An implementation is already in master.

Duplicate of T2819

Yup! Fix works. Thanks, Justus.

Fixed in a98459d3f4ec3d196fb0adb0e90dadf40abc8c81.

Thanks for helping us diagnose this issue. Finally I understood the problem and
was able to reproduce it. Please keep filing bugs :)

voilà: https://gist.github.com/ilovezfs/7979ace5e07e08fbb63155fd78c70d38

I just pushed c7833eca38fdb8d9ba7b59438ea87d651b8bf7ba that will help us
diagnose the problem. Would you be so kind to apply it and rebuild your package?

You're welcome. By the way, you may be interested in this PR since you are
obviously a stakeholder in the matter:
https://github.com/Homebrew/homebrew-core/pull/11083

Please feel free to comment/suggest/etc. if you have any thoughts!

Hi, I have been assigned to this bug, and we'll get to the bottom of this.

The plan is to patch the tests to dump the location of tools it thinks it should
use. I'd like you to run the tests with that patch then.

Thanks for working with us on these issues. It is really appreciated.

Any other suggestions?

Sure: https://gist.github.com/ilovezfs/c0754cd0f5795b4830cc55cec1b0d016

Thanks. Can you please run the test again with

make check BIN_PREFIX=/usr/local/Cellar/gnupg21/2.1.19

macOS 10.10, 10.11, 10.12

They're nearly the same, but T2980 has the workaround for this issue in
place (running make install first), so that it's clear the ssh-import.scm
problem is an independent issue.

So i'm left a little confused here about what the resolution is. neal added
documentation, but ueno suggested it was wrong and contributed a patch for it.
However, that patch hasn't been applied.

Some additional questions about pinentry-emacs and INSIDE_EMACS that came up in
discussion over on https://bugs.debian.org/854797:

    What's the best way to debug a problem when emacs pinentry
    isn't working?  do we look at gpg?  gpg-agent?  pinentry? emacs itself?
    all of those places?  What happens when the user has two separate
    instances of emacs running?  What if there's an instance of emacs
    running and someone uses tramp to connect to a remote ssh server, and
    gpg-agent is providing the ssh-agent interface?  What if someone uses
    ssh from *outside* of emacs and it talks to a gpg-agent that was
    auto-launched from within an emacs session?  What about when there's an
    instance of emacs running in a graphical session on a machine where the
    same user is also logged into the machine via ssh, and they're using a
    different graphical session?  how does pinentry-emacs interact with
    emacs --daemon and multiple emacsclient instances?

Another few questions:

Why does emacs use /tmp/emacs$UID for the ephemeral socket instead of

/run/user/$UID ?

If OPTION allow-pinentry-emacs is set, but the emacs process isn't

repsonsive (or nothing is listening at all) should pinentry do a second layer of
fallback, e.g. to curses?

Duplicate of T1828

Please comment on T1828 (I just granted you permissions)

Duplicate of T2859

That's awesome aheinecke! Honestly wasn't sure if this issue would ever get much
attention. Thanks for the effort in making Gpg4win a more secure product!

Duplicate of T2341

Thanks for your report,

This was already fixed in T2341

Which is currently not yet released. I'm marking this issue here as released
with superseder (duplicate) to keep the tracker clean.

GpgOL is built with DEP and and ASLR now. Need to enable this for GpgEX and some
other parts of Gpg4win, too. So not yet fully resolved but I keep it in mind.

Duplicate of T2359

We track this now under T2359

Duplicate of T2359