And it is merged into master.
Along with the support of multiple readers/token, the parts which assumes Windows 32-bit are fixed, too.

For argparse.c, it can be only stopped with nonnull attribute for the API, I suppose.

I take this so that libgpg-error can be released soon.

The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.

The message has not been encrypted to you. Ask the sender to encrypt to you.

How to fix "failed: no secret key

This is generally the better tracker to report Gpg4win / Kleopatra issues. The git systems are linked in a way that I can both automatically add a commit here and in the KDE tracker.
I just noticed the KDE report a bit quicker because there is less traffic, but I would have seen it here within the day.

In T2300#90092, @aheinecke wrote:

Ah nevermind. I think myself that this is nobug and current behavior is correct.

To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.

There is no need to use the new CTB format for a packet with tag 3. OpenPGP implementations need to support all packet header encodings. We do not plan to make this configurable.

I created a branch for this task: https://dev.gnupg.org/source/gnupg/repository/gniibe%252FT4620/

I could not reproduce such a failure either under any conditions.

Agreed.

yep, the implementation thinks that the default signing key is expired due to metadata contained in the public keyring. The secret key is available to the implementation. So the error mesage No secret key can cause confusion and/or panic if the user thinks they've actually lost their secret key.

In my debian buster pbuilder enviornment I got the following failure when packaging master (beta195):

With the build problem on Mac OS now fixed with d551cf9, barring any last minute issue I plan to do the actual release by the end of the day tomorrow (10 September).

If I understand correctly, the problem stems from the -module flag added to the LDFLAGS in commit dc2211179. It's that flag that instruct libtool to create a bundle (.so file) instead of a dynamically linked shared library (.dylib file). But that flag is needed to force automake to accept that the library is to be named scute instead of libscute (without that flag automake errors out, complaining that scute.la is not a standard libtool library name).

Given that 1.5 already had that problem, I would suggest to ignore that bug for the 1.6 release. We can work on that later.

You mean the default key is expired?

fwiw, i can reproduce this on debian unstable with gpg version 2.2.17, without a redirected agent -- so the agent redirection isn't relevant here.

Today a new signed message from BSI Buerger CERT was received. The PGP signature could be verified by first opening of the document. As I opened the file some hours later again, it failed, as I opened it a third time (shortly after the second time), the signature was verified. Outlook was not closed between the second and third opening. Signature verification appears unstable.

@stm -- thank you for this!

There is no reason for apologies :-). As far as I know this all is open source, freeware and you don't get paid for this, right? So, I simply also try to add my contribution by most precise error reports to help to find the error and am grateful if it will be solved one day in the future :-).

Gpg4win-3.1.8 was released.

As far as I know this works.

This works but might have created a regression which is tracked in T4701

I give this normal priority even if it is a whish because I have the same whish and already have some code around that would make it more comfortable, especially if it is used directly in GpgOL.

I still would like to test this some more and work on it. I think the implemnation might still be a bit fragile.