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.

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/

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.

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 :-).

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.

Oh, this report is about libgpg-error.

Thanks for the sample certs. I noticed the posts but had not the time to look into them.

I have the same problem since today with Outlook 2016. In the past months / weeks GpgOL version 2.4.2 worked fine. I received some mails today signed by the German Buerger CERT warnings. The signature as "asc" file was attached, but could not be verified. Today I received also a PGP signed e-mail from Hasso-Plattner-Institute (Identity leak checker), also this signature could not be checked. Both worked fine in the past and the public keys stored in Kleopatra are valid.

Would be great to see this fix rolled out! Absence of support for these keys disoriented me for months after switching to pinentry-tty. I use my longest passwords for GnuPG, so being able to fix typos (instead of abandoning password entry altogether) would be greatly appreciated.

@werner How can I install libgpgme-develp package on windows 7?

Sorry, we don't use or support PIP. Please ask whoever packaged that for PIP.

... https://lists.gnupg.org/pipermail/gcrypt-devel/2019-July/004760.html

If helpful I can demonstrate or let you debug in a TeamViewer (I have a license) or VNC remote session in a fresh VM.
For sure this is not urgent for me. So, take your time!

Mmh, No Data usually means that our parser had a hickup. I'll look at your examples.

Mmh, No Data usually means that our parser had a hickup. I'll look at your examples.

The Python doc build system we implemented the last year is a complete mess - I had so much trouble the last time I did a release :-(.

Hi Andre,

Strange. Can you please go to the command line (cmd.exe) and run gpg --verify "c:\<path to>\gpg4win-3.1.10.exe.sig" "c:\<path to>\gpg4win-3.1.10.exe.sig"

can you hover over the GpgOL Icon and look at the tooltip? Maybe there was an error during validation.

Account disabled and I'm closing this as resolved.

Thanks. Fixed in stanble and master.

I am sorry it just needed to be run as root.

For information, I can’t reproduce here, either with GnuPG 2.2.17 / Pinentry 1.1.0 or with a fresh build from the tip of the master branches. Both pinentry-tty and pinentry-curses prompt for the password as expected, independently of whether the file to decrypt is specified as an argument or sent through standard input.

i'm actually running make -j3 check, since make -j3 distcheck has the problems described in T4688.

So i've been able to (intermittently) reproduce the failures that i think @werner was alluding to here, but not under any circumstances where i can get them to happen reliably to understand what's going on.

Please read my answer again. Posting to gnupg-users does not require a subscription.

Please do not force me subscribe to yet another mailing list to see the answer.
So do you have any plans to make new release? :)

See T4683 and T4684.

oops: That was an accidential priority change

Implemented master and 2.2. Note that the comment in the master commit about possible reason for stucked keylisting in gpgsm is only related to master.

I implemented it nearly as suggested. However, the default AKL is used, which is "local,wkd" (local is not used with that command though).

Fixed for 2.2.18. To allow seeing these warnings this change will only have an effect if a listing of all keys is requested.

Done for 2.2.18

This was already fixed with version 2.2.5.

Will be in 2.2.18

I changed the suggestion to read:

The agent is an important part of gnupg and it does not make sense to single out cases when it might not be needed. I can't see any harm from having an agent running. In fact, one of th netxt versions will add yet another daemon which will then be needed in all cases.

Thanks, @gniibe. From reading this patch (i haven't tested it), it looks like it would avoid most unnecessary agent launches (and agent communication) in the (b) case, which is a win over the status quo.

With me it happens all the time: Outlook 2013 x64 is half-maximized at
right border, and GPG asks for the passphrase on sending a mail from the
inline editor, on Windows 7 x64, then it always happens.

Thanks.

If it makes sense to warn a user for someone's preference when keys are imported,
here is a patch:

i've just pushed rGc4b9eba1d6a63b73238dcbb644b365dc53563f3d to the dkg-fix-T4682 branch resolve this.