Thank you for your detailed report!

Fixed for master and 2.2.9.

Will be released with 2.2.9

Fix will also go into 2.2.9

Do you have Tor or the Tor Browser running? Dirmngr will use them instead of a direct or proxy network connection. Di disable this behaviour put

no-use-tor

into dirmngr.conf. If that is not the case we need some more debug info. Put

log-file SOMEFILE
verbose
debug network,dns

into dirmngr.conf and post the log file (or send privately to wk@gnupg.org mentioning T4044 in the subject - no HTML please).

This is really minor, just wanted to report it so it did not get forgotten.

I don't think that this was ever working the Outlook 2007 code has been pretty much unchanged since 2013.
According to T1137 a workaround seems to be to enable the S/MIME Support in GpgOL.

Thanks very much for your help! Could you please tell me the latest version, that is running without any mistakes on outlook 2007?

Outlook 2007 is no longer supported. Neither by Microsoft nor by GpgOL. Sorry for that. But the 2010 and later GpgOL had a completely different codebase and we had to remove the support at some point.

Fixed in master and 2.2 branch.

I found two more cases. Those are included in the fix.

Maybe a first step would be a "KEYLIST_MODE_WKD" which sets "auto-key-locate clear,nodefault,wkd" (Would be nice for T3910 ) or just a ctx_flag "auto-key-locate" so that the caller can decide?

I'm pretty sure that the running command ist the reloadkeyscommand.

Good catch. Thank you.

The cause is: ! in nsswitch.conf
This was fixed (2.2 branch) by rGd4c0187dd931: libdns: Hack to skip negation term. for GnuPG in Jan 2017.
I found it was fixed in the original libdns, and this fix is merged into rG20c289606f89: libdns: Sync to upstream. to GnuPG.

Werner please give an opinion / triage.

Good news! :)

Just as a note as you were the first to report this: I've finally found a solution. In the next version it will be possible to move around crypto mails. Hopefully your wife can then use GpgOL :-)

The new idea worked! It is now possible to move mails even while their decrypted content is shown!

A new Idea which I'll have to test:
Register an event handler for each folder in which a decrypted item is read. "Mailitem->parent" In this event handler listen to the beforeitemmove event. In that event then close the mail / discard the decrypted contents.

Thanks a lot!

Will be fixed with the next release. With the next release kleopatra will only set "allow-version-check" once except if the user explicitly selects "help -> check for updates".

Right. The only way to disable it is if an update notification pops up. If you then unselect "Show this notification for future updates" it is disabled. And you only get to that dialog if there is an update check.

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.

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

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

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

Applied to 2.2 branch.

For the problem in the last comment, it was fixed in T2928: stop fetching PTR records entirely.
For the original issue, it looks that EINVAL is returned by the system call of connect(2).
That's quite strange, but, it was possible for IPv6.

Hi Werner,
I have performed some experiments on the issue I have and the following are the results:

As expected it was a very clear bug. We assign a NULL pointer to a string and then use that string.

Thank you for the report and the logs! A minor note: For future reports please leave the priority on "Needs Triage" we use this as a marker for issues no developer has looked at previously.

Fixed in repo (master and 1.8 branch).

Thanks for your report.
You are right.
Simply getting the information for "rng-type" through gcry_rndjent_get_version will hang.

Investigated the "why not with glibc" question this morning, appears that the test triggering the hanging behavior (version) happens to not be linked with -pthread and so locking calls do nothing. Manually adding -pthread causes it to hang with glibc as well.

See also: https://github.com/NixOS/nixpkgs/pull/42150

Thanks for forwarding.