The problem was created during a migration of the host operating system and acme client tools.

bug has been closed as Wontfix [..] I see no reason to continue the discussion in the bugtracker.

It is now over 10 months that the proponents of these additions have not followed up on the discussion.

dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems.

Reading the mozilla entry more carefully, there still seems to be an issue.

https://blog.gerv.net/2012/01/mozilla-projects-and-gpled-code/

@kaie, thanks for the pointer!

Using GPGME is probably the best way, even if gpgme-json might also work for some operations.

ok i found it just add "trust-model always" in gpg.conf

Hmm your log does not seem to indicate that the key is requested by GnuPG,
e.g. something like

rmngr[6077.5]: DBG: chan_5 <- KS_GET -- =bernhard@intevation.de

is missing.

i dont have one what shoud i put in it

Tried it myself, getting the pubkey seems to work here.
Debian gnupg Version: 2.2.27-2~bpo10+1

Did you try "--auto-key-retrieve"?

Can you show the output of the command that works and the command that does not (and gets called by evolution),
please also add a "-v" to the options.

It could also be a problem of the keyserver (some hagrid instances are known to deliberately break RFC4880), can you try with a different keyserver, e.g. http://keys2.andreas-puls.de/.

@FloorVeil thanks for testing!

There is another report that it works in 3.1.16 again in
https://wald.intevation.org/forum/forum.php?thread_id=2044&forum_id=84&group_id=11

Could make --multifile work on windows 10, documenting the workaround here.

https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works has

I've also suggested 3.1.14, but the changelog for 3.1.15 lists two potential important defects fixed for GPGOL (the empty recipient and the auto-retrieve).

https://wiki.gnupg.org/Gpg4win/RunAsUser has more explanation about this, and I had to give this to quite a number of people in support. (An improvement to the could be a link to a very good external or official explanation, does somebody know one? I've searched briefly but was not successfull to find strong recommendations by Microsoft.)

@werner should the pros and cons of mkportable be discussed here or on a mailinglist?

A second report came in via https://wald.intevation.org/forum/forum.php?thread_id=2044&forum_id=84&group_id=11

(For completeness, people don't know if there was no documentation change, so if anything strikes them as strange, they cannot say if this is because they don't have the right version of the documentation.)

to explain a bit more: This report was opened after the reported defect was already fixed.
As we are getting many reports and technical suggestions, please keep the reports focused on one point only if possible
and open general discussion points about development improvements on gnupg-devel@.

Can you point me to a more elaborate list of the general concerns? (Central directories offer some sort of stable history, namespace and API service towards identifying modules, just like the venerable https://www.ctan.org/ . The solutions built on such services, like programming environment specific "package" and dependency managers that download and install thousands of packages automatically (like yarn) may be debatable, but I am not aware of much general concern against the services itself.)

@werner, that is a missunderstanding:

I may attempt an update here, who has the pypi maintenance account?
(If we don't have it, we need to ask Justin or create a ticket with the PSF.)

The user reported to

Hi Werner,

can you elaborate?

A backtrace with gdb from migw-w64 results in

I did a fresh install of Gpg4win 3.1.14 and imported my standard pubkey, by using

gpg --locate-key bernhard@intevation.de

on the command line.

@s7r Thanks for testing and letting us know!

Thanks Werner! Seems like an important step!

Thanks for the quick analysis.

Observation:
The umlaut is displayed incorrectly on the command line (cmd.app) when the keybox file is created.
(This may or may not be relevant.)

Last report more than two years ago.

--locate-external-keys exists since 2.2.17 and ignores the local keys.

On the ml there was another request for this use case

Read through it, thanks for the updated description!

Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.

Hello,
just reading the issue in detail.

Just reading this issue in detail.

@dkg while I agree with your aim of

Just added a comment to T4826 how to move forward, if this is still interesting for parties. Right now (from my point of view) a pubkey with an expiration date beyond 2106 is not a sensible key configuration, so the use to motivate a chance in this area would need to be argumented better.

This issue, as well as T4766 has the challenge that there is a disagreement about the usefulness of the use case, as far as I can see.

To explain the use case, I've started coming up with a good passphrase and this took a bit of time with a pencil and paper in front of me. When I wanted to type it in, it was too late. Thus I guess that some people will look up good rules of passphrases or at least make sure they can remember the one they are typing in.

How do I know that you've noticed?