A better solution has been commited: cc6069ac6ecd

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

We did not remove the "<>" from the content id. This worked for the first display but when forwarding they got doubled and it broke.

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.

We only supported SHA-1 signed OCSP requests. Fix will go into 2.2.16.

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.

fix build with a fixup that got applied twice. better benchmarks

I doubt that we are going to implement this.

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.

No sorry, we won't do that for the regular source. However, the full source for the binary installer is xz compressed. That is because we are legally required to publish the source but in reality the source ist not used and weel, to build you have lots of other requirements with xz being the simplest one.

proper benchmarks

Fix alignment needs of vcrypto instructions.

I guess we can do that. Thanks for the hint.

Interesting tinge: The main CRL of the dgn.de CA uses a nextUpdate in the year 2034 (15 years in the future) which would force dirmngr to cache the CRL until then. However, the CRL of the intermediate certificate has a nextUpdate only one month in the future. There is currently no entry in that second level CRL, so their idea might be that an updated second level CRL will also trigger a reload of the main CRL. I have not checked how we implement that in Dirmngr but I doubt that such a thing will work for us and that it is in any way standard compliant.

Consider using tests/bench-slope to get cycles/byte results so they can be compared with https://github.com/dot-asm/cryptogams/blob/master/ppc/aesp8-ppc.pl#L34

Didn't do sufficient testing.

Actually include modified perlasm file.