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.

I'll try to look at it this week. Apologies for the delay with this.

Last week GpgOL again destroyed an email with a BSI newsletter - it was shown as empty after I opened it a second time - and the same is true in such cases then in Windows 10 Mail as well as using Outlook Web Access:

But this problem remains for several versions for some time. I tried to find out the source of this "new option" in the communication, but I could not find anything about "GPG Agent" in the source code of openssh.

Sorry for the late answer, but I have been busy. Actually this happened against several ssh versions, for some time now.

The signature of the latest communication from German Buerger CERT Warnings could be read and the signature could be verified. I tried also with Hasso-Plattner-Institute (Identiy leak checker), the same result. I do not understand, why all signature verification failed last week, and they can be verified this week. However, at the moment it seems to work fine.

I just checked that Scute builds cleanly on Slackware, Debian, and in a cross-compilation setup against Mingw32.

Here is an example containing such a Attestation Signature:

Oh, this report is about libgpg-error.

Poly1305 addition helper for ppc64 posted on mailing list: https://lists.gnupg.org/pipermail/gcrypt-devel/2019-September/004804.html

This seems to be closely related to T4319 and due to to some, ahem, interesting configuration.

BTW: I have the problem that I want to know the keys of all cards. "getinfo card_list" along with --demand can be used for this. gpg-card works this way. It does not work if plug in addtional cards becuase card_list shows only the cards for which a SERIALNO command has been used. A new feature to scan the buses for all readers and cards would be quite useful.

Still there are two places where we use "SCD serialno --demand <SERIALNO>". One is g10/skclist.c where we list available keys, another is the funciton card_key_available in agent/command-ssh.c .

By the change of rG9f39e0167d06: agent: Fix ask_for_card to allow a key on multiple cards., the SERIALNO in the stub is just an auxiliary information, not identifying the card. Now, it is the keygrip for key to identify/select the card.

Thanks for the detailed implemention plan. For the include-historic et al things it might be better to make use of the filter-syntax. I am not sure what is bets but that get clearer during coding. First step will be to add a parser and to silence 2.2 about this. I can imagine to later backport some basic functionality to 2.2