Compressed packets in detached signatures and/or certificates have never been permitted by any version of the standard.

In D555#5569, @werner wrote:

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

In T6031#159248, @werner wrote:

{please add comments instead of adding the description - a changed description makes it hard to understand follow up comments. I will change the title, though for clarity.]

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

I will try, but it will likely be a while. In any case I believe you will need a Red Hat-family distro to trigger the bug; it happens when gpg trys to encrypt with a key that uses a public key algorithm libgcrypt does not support.

Please provide a test case.

Reopening as it appears this issue was closed based on an incorrect understanding of what it is.

Reopening as gpg’s handling of the situation is very much suboptimal.

I pushed the change needed for GnuPG to t5964 branch.
See: https://dev.gnupg.org/rGc281bd94349e4f7997a89927aaa2c2f45004b902

Added HKDF implementation to master.

Applied to 1.10 branch.

didn't seem to work with 1.9.x

Closing as I believe this is a downstream bug.

Please read at least one article that explains how to write a good bug report. I'm pretty sure that you will find plenty of good articles using your favorite search engine.

Thanks! Interestingly didn't seem to work with 1.9.x but it does with 1.10x. Maybe I made some error when testing.

I found this page:
https://firefox-source-docs.mozilla.org/security/nss/legacy/nss_tech_notes/nss_tech_note2/index.html

In the branch https://dev.gnupg.org/source/Scute/history/t6002/ , by the commit rS123d617ebefe: Less administration of devices by scute., things has been changed.

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

Here is a test signature with long notation data. During verification gpg faults when emitting the NOTATION_DATA lines.

As Werner wrote, this is already possible. The next time please consult the extensive documentation of gpgme before opening a ticket.