Backported for for 2.2.37

Fix will go into 2.2.37 and 2.3.8.

Probably fixed meanwhile in 2.2.
Please re-open if experience this problem also with a decent gnupg 2.2 versions.

Probably an invalid specified keyserver

That is not easy to change because we show all kind of error codes. If you run in --verbose mode you should see more info.

There won't be any semantic changes for obvious reasons.

Thanks for reporting.

The first thing is a problem of the GNU makeinfo tool. Can't be fixed int the source.

Please note that due to vacation issues the signatures use the gnupg.com Brainpool based release key and some Linux distributions come with Brainpool removed from GnuPG.

The first ideas sounds best to me. Patches please to the mailing list.

ACK. P[ease add it also to 2.2.

What about rejected changes to "Key:"? Other this command would make it too easy to mess up the actual private key.

I fixed the title, because it is not a Windows only issue.

The mentioned "g10: Fix garbled status messages in NOTATION_DATA" has nothing to do with the problem. So it can'r be the actual cause. Anway, I hope to get a 2.2.36 out this week.

iirc, we use ftruncate for ages now. The problem with the name ftruncate is that it looks to similar to the stdio functions. But sure, things should be flushed first.

The likely cause is that the secret key is not protected. Problem seems to be in gpg-agent.

Looking again at your report, I don't think it is an IPC problem (bad magic cooky was my assumption). I can replicate this with the current 2.2 but not with 2.3. Both un Unix.

Please don't play ping pong now,

Please report such bugs to RedHat - they use a modified Libgcrypt and thus it's there bug.

Sorry, there is no padding packet in OpenPGP. Please do no try to push ideas from that crypto-refresh-06 thing into GnuPG. We continue to follow the last draft with consesus, which is rfc4880bis-10.

The length limit of the signature sub packets are not reasy to pre-compute. Better to have a fatal error than a corrupt message. I am not sure whether we want to change this to a regualar error message - at that point we anyway need to stop.

You deleted the socket file but you did not restart the agent. Thus gpg can't contact the agent anymore. On Windows we use a socket emulation which requires the socket's file only for a new connection (to get the port and magic cookie).

Please provide a test case.

When I replied to the bug report I had the very same idea. Thanks for adding.