We didn't found the time to organize it. There will be a OpenPGP summit this fall organized by Patrick, though

Will be released with 2.2.9

Fix will also go into 2.2.9

changing to testing is our marker for "done in code but not fully tested / released". It helps to keep an overview of the issues which are "done" for the next release.

Hi Andre,

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

We have two cases:

1. No MDC with a "modern" cipher algo

This is implemented now and can be turned of in the new config dialog.

ASCII Armored CMS files now also use p7m and p7s this is already handled gracefully by Kleopatra and does not require us to register new filetypes.

I find this better then a new "KEYLIST_MODE_WKD" as it is more flexible and this flexibility with context flags is currently our thing anyway.

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.

Backport done. To be released with 2.2.9.

Fixed in master and 2.2 branch.

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

User input, anything to solve the lack of entropy on servers would be *great*. We have a bunch of buildbot workers we would *love* to have sign their artifacts... however we end up (unsuccessfully) doing stupid things like this to try and drive up entropy as a non-root user:

I am not sure what you mean by “keybundle”. Is is a single keyblock or a selection of multiple keyblocks?

Looking at the table in random(7) it seems clear to me that what we want to just invoke getrandom() with no arguments. This blocks until the kernel's PRNG has been adequately seeded, but once seeded it doesn't block, while still pulling from an unbreakably-strong PRNG. this is the best-of-both-worlds situation that we want.

Changing the GnuPG long-term (and short-term) key generation techniques to use this approach might require coordination with gcrypt. gcrypt's gcry_random_level currently has GCRY_WEAK_RANDOM and GCRY_STRONG_RANDOM and GCRY_VERY_STRONG_RANDOM, which doesn't represent the nuance described above.

One approach might be to just have gcrypt on Linux treat all values of gcry_random_level the same, and use getrandom() for all of them.

ping again…

Ha, I wish e-mail-like searches would be done using only WKD with no fallbacks to keyservers... that way keys would be "more verified"... but I understand it may be not practical :)

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.

Attaching files is gone, but here they are inline:

Werner please give an opinion / triage.