It's currently enabled again with 27e7dfb1280f314286348a661e057eef5c8ab440 I had another intensive look at the logs from the user where it is crashing but I still don't see a problem.

Ahh there we go... I just did a --recv-keys to update from the keyserver and that picked up the extended expiration date.

The problem here is that we we did not sync the pubring with the secring in old version (2.1 removed the secring concept also due to that syncing problem). Now if we migrate (or plainly import a secring.gpg), gpg does not see any updated self-signatures and this is the reason why outdated self-signatures are used.

GnuPG itself does that in in gnupg/g10/migrate.c. We need to fixed this.

Done for master. Needs backport.

I implemented it in master and if you agree I will backport it to stable. This is the new output:

Am 21.06.2018 um 10:31 schrieb aheinecke (Andre Heinecke):

aheinecke added a comment.

Beware: Beta-7 was bad timing, yesterday I was in the middle of
implementing T3999 https://dev.gnupg.org/T3999 and broke the
internal keycache. If you use "Empfängerschlüssel automatisch
auflösen" please switch back to a different GpgOL Version. I might
upload a new Beta soon but for now I've removed Beta-7. Automatic
resolution will not work with that version and can lead to crashes.

*TASK DETAIL*
https://dev.gnupg.org/T4037

*EMAIL PREFERENCES*
https://dev.gnupg.org/settings/panel/emailpreferences/

*To: *aheinecke

*Cc: *aheinecke, JJworx, Rafixmod, ccharabaruk, Mak, gp_ast

This is an automated email from the GnuPG development hub. If you have
registered in the past at https://bugs.gnupg.org/ your account was
migrated automatically. You can visit https://dev.gnupg.org/ to set a
new password and update your email preferences.

Beware: Beta-7 was bad timing, yesterday I was in the middle of implementing T3999 and broke the internal keycache. If you use "Empfängerschlüssel automatisch auflösen" please switch back to a different GpgOL Version. I might upload a new Beta soon but for now I've removed Beta-7. Automatic resolution will not work with that version and can lead to crashes.

Not really. off_t is a real portability problem and this why we moved that problem out of the GPGME ABI to the application. Thus the application needs to care about mapping gpgme_off_t to whatever off_t it uses. Without that we can't provide a stable _and_ toolchain independent ABI.

Thank you for your feedback.

Thank you for pointing this out.

Following patch fixes the issue.

We should include the man page then in texi format into tools.texi

Worked for me (T4035).
__outer

Yes, that did the trick for me!

Nice, then my commit should fix the issue here.

Yes, definitely the real reason is in the inline editor.

I can't confirm the regression yet. For me (albeit with Outlook 2016) preselecting sign / encrypt based on the options works for reply and forward. But only as long as the Mail is opened in a dedicated window.

It's manually written one in Debian:
https://salsa.debian.org/debian/gnupg2/blob/debian/master/debian/gpg-check-pattern.1

I manually configure IPv6 only environment, and now (forthcoming 2.2.9), it works fine for me.
So, I move this state to Testing.

Thank you for your fast fix!
2.2.1-beta2 works as expected!

• dirmngr fix for --recursive-resolver: rG5b40338f1276: dirmngr: Fix recursive resolver mode.
  • After the release, we can ask using this mode not to use nameserver in /etc/resolv.con, but resolve by libdns directly
  • Possibly, these bug reports are related: T2968: gpg --search: Connection closed in DNS, T3168: dirmngr: gpg: keyserver receive failed: No keyserver available, T3517: dirmngr: retry without SRV due to buggy routers