I think this commit should be reverted -- if the test fails we should figure out why and fix it, because the logic of the test is correct.

It also passes for me with python 2.7.16 (debian package 2.7.16-2).

i think you mean t-decrypt-verify.py, right? That seems to indicate a problem on the targeted system that we ought to fix, rather than just commenting out the test. t-decrypt-verify.py passes for me when i test it with python 3.7.3 (debian python 3.7.3-1). what version of python are you testing with?

Unfortunately this is not the case. I had to remove the test code from t-decrypt-verify.c (7d0a979c07d2) to let "make check" work.

Sorry for the truncated commit. the sentence should have been:

This is all valid Bourne shell syntax. In detail:

Release done.

Can you please explain the commit messages. It seems the message was truncated.
And a failed test is a no-go in the regression test suite. A make check fails and thus the make release (or make distcheck) won't work either.

I have a larger change for the wait code in the works. This will go into 1.14.0 but not in 1.13.1

Thank you very much for your quick action!

Hi Andre,

Hi,
as usual, thanks for your help.

@gouttegd good catch!

The reason for this is the change to Kleopatra that the columns are configurable ( 4847fcc27afc8101752de82b0dd1f5fee027695d ). In the process we added additional columns like origin and to hide the "summary" column that the line edit for the recipients use we gave it an index number that was higher then our internal column count.

Thank you very much for the report. I can see this problem myself. It is strange because the code for that has not changed since 3.1.7 so it must be some sideeffect.

Thanks for the hwf-ppc.c. I've pulled the latest from upstream, applied the patches, and gotten the updated library built. Will let you know of any feedback from our performance team.

Thanks a lot @gniibe for this change.
I do understand and share your concerns, nevertheless are there, in my opinion valid reasons to be able to have a backup or duplicate, especially on the same or similar media type.
Consider for example giving multiple devices a chance of common interaction, using the keys for backup encryption etc. - I think there are several possible use-cases which can benefit from this.

I don't mind how we call it in Libgcrypt. For GnuPG we should use "cv448" me things.

I just assumed that is an ntbtls problem.

If I understand correctly, this is exactly the same problem that the one we encountered some time ago in the code dealing with fetching keys from HTTP (--fetch-keys), and that we fixed with this patch.

Regarding OCB: I do not want to touch a patent-encumbered algorithm (3 more years) which claims to force only GPL usage of libgcrypt[1].

fwiw, the bug looks like it's in send_request in ks-engine-hkp.c, which re-uses the http_session object without re-initializing its tls_session member.

Have you considered working on bulk CFB-decryption and OCB-enc/dec? Those are the block cipher modes used by GnuPG (OCB is new AEAD mode to be used starting with 2.3).

thanks for the triage, @werner!

We need --keyserver in gpg for just one reason: backward compatibility.

thanks for fixing that error message, @werner. As @Valodim points out in discusson about hagrid, a gpg.conf keyserver option (deprecated according to the documentation) overrides the dirmngr.conf keyserver option (not deprecated according to the documentation.

I'm having a very similar problem in 3.1.5! Randomly, when I try to view a PGP-signed e-mail, nothing shows, both on preview panel and when I open the message.

rebase

correctly generate the asm for it's "linux quirk" mode (fix build on big-endian)

It turns out that the upstream cryptogams is broken on ppc64 big-endian elfv1. I reported this upstream https://github.com/dot-asm/cryptogams/issues/5 (openssl version works fine)

include hwf-ppc.c

We are trying to apply patches in order to conduct internal testing. They did apply successfully. However, we can't get the result to link because _gcry_hwf_detect_ppc is undefined. Is there a hwf-ppc.c somewhere?

I received an strace for a similar case by PM.

File->Save As now works for crypto mails. It saves the encrypted message.

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!

This works now, the hidden BeforePrint Event enabled us to detect when a print happens and the old code to do blocking decrypts enabled the actual printing.
We also do not print "our categories" (encrypted message, level x trust),... anymore, even in quick print.