This is a high prio error, I guess, because it breaks a very useable part of gnupg, that is really hard to maintain. If it is not stable to sign keys with the gpg-agent, it is very hard to use that. Many might switch back to the ssh-agent.

Please check if this patch works for you and please check where this flag actually comes from and what it does say!

Fixed in master.

any feedback on this proposed patch?

I did forget to mention that the key I'm using is 4096 bit long

I was creating a tar archive with 7-Zip on my Windows 10 machine. After the creating was completed I was encrypting the archive like so:

Just to clarify, you were able to decrypt and extract it without error? Which tool did you use to extract the tar archive?

The solution conflicts the the fix suggested and implemented for T4330.

Fixed similar to the suggestion but NaN and INF are detected earlier.

I did encrypt the file myself with the version mentioned above.

I see the regression of gpgconf. I wonder if it's better to fix gpgconf side, too.

I see a regression with your fix. This option is even controllable with gpgconf at the basic level. It would be better to make it a dummy option.

Fixed in master. Closing.

Fixed in master (to be 2.3).

I tried to apply&push, since we changed the file a bit, I needed to apply it manually.
Anyway, it's done.
Closing.

I meant, 'card-timeout' was not intended for controlling caching PIN on card. It was for "DISCONNECT" command support.
I'm going to remove questionable documentation.
Closing.

No worries -- you led me in the direction of a solution when you mentioned loopback mode. I appreciate your time and your help!

Thank you for your fix suggestion. I think your change is good. I applied and pushed.

Sorry, I responded in a mode of "tracking a bug to fix soonish". I should have changed my mode into showing HOWTO.
Thanks for sharing useful link.

I found these instructions for pinentry loopback in Emacs, and they worked!

When you can configure it properly, there is a way to workaround it.

A newline is required by the PEM standard.

Maybe the file was encrypted with a version of gpg4win-3.1.5? We had a serious bug there that sometimes files were corrupted. See: T4332

This is problem of your setup of your build environment. Closing.

I added the section in tools.texi. Closing.

For (1): it is broken out-of-the-box, that would be true. When you can configure it properly, there is a way to workaround it. Well, I admit, it's not yet perfect.

Thank you for that analysis. I don't understand some of the parts (because I don't know anything about pinentry), but I do have some questions.

Thanks for your report. The symptom you have could be only solved by using pinentry loopback mode, or using some special pinentry for CLI, I suppose. pinentry-tty is not sufficient for this usage.

Please let me know if I can run any other tests to help debug this issue. I'm happy to help.

FYI, pEp annoyance was addressed and handled here: https://bugs.debian.org/891882
By this patch: https://sources.debian.org/src/enigmail/2:2.0.11+ds1-1/debian/patches/0002-Avoid-auto-download-of-pEpEngine-Closes-891882.patch/

Thank you for your response.

For GnuPG, the error is: you don't have run-able libntbtls.so in your environment (because of your wrong configuration, perhaps) but you have it to link.
For GPGME, the error is: your linked libgpg-error.so.0 and the one which runs are different (because of your wrong configuration, perhaps).

I've pushed fa0a5ffd4997c2ca38a1dd2d89459b6b1f18ad99 to the branch dkg/fix-T3464, which i think solves the problem i was seeing without reintroducing any new problems.

I can confirm that this is actually a problem now :( gpgme_op_decrypt_verify returns a status with GPG_ERR_MISSING_KEY set when a session-key is used.

we've never shipped a binary gpgscm in any debian package. I was just reviewing the differences between what we ship and what upstream ships, and i noticed this discrepancy.

I also experienced this issue while testing my --delete-secret-key patches. Passing --pinentry-program /usr/bin/pinentry-tty to the gpg-agent worked around it.

Thanks, the mentioned OpenSSL option should be helpful.

A high level test description is:

1. Configure both gpgsm and dirmngr to use OCSP.
2. Import the responder signer certificate with gpgsm --import.
3. Use a certificate with OCSP responder extension present, or configure a default OCSP responder in dirmngr.
4. Configure your OCSP responder to identify itself with key ID (and not subject name)
5. Attempt to sign or verify with gpgsm.
6. You should get an error, with dirmngr logs showing that the responder signer certificate could not be found.

Thank you for a quick fix (despite this being a minor problem).

Thanks for taking the time to describe this attack vector. We will need to study this closer to balance such a change with other side effects of this.

gpgscm will anyway be moved to libgpg-error and then installed as part of that package. Given that we install it for quite some time with gnupg, I won't remove it unless we can be sure that it has been installed by libgpg-error. Feel free to remove it from Debian, though,

I wrote a patch in a topic branch: rG108c22c9c50a: g10,agent: Support CONFIRM for --delete-key.
I think that gpg-agent side,

• agent/call-pinentry.c: This part is good
• agent/command.c: I wonder if use of status for passing the information of prompt is good or not

Perhaps, we need an improvement in

• g10/call-agent.c: how to ask user, by cpr_* function with no keyword is good?
• Currently, only using DESC
• Only applying to DELETE_KEY command
• Can be applied also to:
  • PKSIGN
  • PKDECRYPT

I do not have a PoC (or much interest in making one, I have too many more important things to do), but I believe this to be correct, based heavily on PPC knowledge of Nicolas König <koenigni@student.ethz.ch> . This attack also applies to AMD, Intel, and ARM.

I should add that using gpg on the command line works fine over SSH. The problem occurs only inside Emacs over SSH.

Ah, I added the --verbose option and got this output (sanitized by me):

Sorry, I forgot to mention it. You need to add -v to the command line.

Thank you, werner. Could you please tell me an exact GPG command to do this signing, and tell me where the output line should appear? I tried this command on the command line:

Which pinentry are you using in in what mode? Please do a sign operation and watch out for a line similar to:

My understanding of this issue and the fix for it is that Outlook with exchange detects that our mails are S/MIME mails. As the attachments are modified by us outlook wants to save the changes on move. This fails because it can't do the crypto. Leading to the error. This also happens when such a mail is closed.

I also tried adding this to my gpg-agent.conf file:

Oh, in case it wasn't clear, the idea that another application (GNU emacs) is receiving keystrokes meant for the gpg-agent prompt is probably a security risk....

Do you have any test cases? Note that T3966 is due to missing support for SHA-256.

Can you please give more details and tell whether this is powerpc specific.

The code had the assumption that a content-id
could only exist on an attachment for HTML mails as it otherwise
does not make sense.

Thanks to your very good analysis, this was easy to fix.

@werner Thank you for resolving this issue.

See the man page on how to delete subkeys or just the primary secret key with --delete-key.

I was able to reproduce this when I forwarded the mail after opening it in a new window. Somehow that appears to influence it.

I think that when using GNU autoconf's configure, you should have the ${prefix}/bin in your PATH.