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.

Changed

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.

T3961 Needs this
T3999 also