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.

fix ctr mode when counter overflows.

resolve merge conflicts

It might have unwanted side-effects - I am not sure. Anyway for me it works.

I've added few new CTR test vectors to tests/basic.c for checking 32-bit and 64-bit carry overflow cases, rC971d372f512ff6805d5b8b54e9ac1446f3f66643

If it is that simple I really do not understand why this is not upstream. o.O

LGTM

Good catch on using the counter to foil "smart" algorithms.

I had to patch strace to follow threads but not forks (P8) and then when built with support for -k I tracked it down: In the inbound handler we close the fd immediately on EOF. However the upper layers don't know about it and a select fails with EBADF. Of course we could ignore the EBADF, figure out the closed fd and restart. The problem is that another thread may have opened a new oobject and that will get the last closed fd assigned - bummer.

Just noticed that due to me failing to properly understand re-entrant locks the run-thread test is broken at least on windows in that it never waits for completion. So running out of filedescriptors is to expect. I'll fix the test.

My observation from running the verify threaded test on windows is that it does behave differently. The EBADF does not occur.

Nope

• --import-options restore
  • Implies
    • import-local-sigs
    • keep-ownertrust
  • Turns off
    • import-minimal
    • import-clean
    • repair-pks-subkey-bug
    • merge-only

• --export-options backup
  • Implies
    • export-local-sigs
    • export-attributes
    • export-sensitive-revkeys
  • Turns off
    • export-clean
    • export-minimal
    • export-pka
    • export-dane
  • Causes build_packet_and_meta() to be used instead of build_packet()
    • This variant also writes the meta data using ring trust packets.
      • a8895c99a7d0
        • Ring trust packets are implementation defined and have always been used in gpg to cache the signature verification status.
        • Ring trust packets are only exported with the export option "backup" and only imported with the import option "restore".
        • As a side-effect of this patch the signature status cache works again and "gpg --check-sigs" is thus much faster.
      • RFC 4880 § 5.10
      • doc/DETAILS

Here are the patches without any new commands:

New commands can't be introduced.

New commands can't be introduced.

@werner Only patches 2 and 3 introduce new commands. What do you think about the other changes?