When changing the filel contents of C:\Program Files (x86)\Gpg4win\VERSION from

Gpg4win-3.1.15

to

3.1.15

the update check works again.

rW4dcba538b74e2ad2d64adb4273176a4e4f85e599 changes the contents of the VERSION file as part of T5056 both on 2020-09-20.

Well spotted @ikloecker !

@ikloecker Note you can easily setup a test instance using one of Microsoft'S test VMs, see https://lists.wald.intevation.org/pipermail/gpg4win-devel/2021-October/001769.html

We should disable the menu button until it is fixed. I think it should be on the roadmap of 4.0 to have this working.

Adding GPGME_DEBUG with 9 to the logs, there is not much more to see:

With the following settings done as described at
https://www.gpg4win.org/doc/en/gpg4win-compendium_29.html

@werner can you prioritize?

This has not been set high on the priorities, because keyserver access works for most with Gpg4win (and thus GnuPG) on windows. A recent exception has been occurred about a month ago with Let's encrypt expired root certificate. So currently for Gpg4win 3.1.16 you need to update to a newer GnuPG (Version 2.2.32 at time of writing), by installing the simple installer,e.g. https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.32_20211006.exe

@werner, because we have talked about it:

@rupor-github no problem for the delay. Thanks for explaining!

My experience on a Window 10 system (with Gpg4win 3.1.15 which has GnuPG 2.2.27) was, that removing the expired root certificate did not help with https://keyserver.ubuntu.com and the intermediate certificate was not in the windows store, so it could not be removed.

One problem I see is that keyserver.ubuntu.com delivers a problematic intermediate(?) certificate:

If there is no easy way to install a new version of GnuPG, e.g. for Gpg4win or for GNU/Linux distributions: It may make sense to have instructions for the workaround ready.

Looks like this should be handled in the Enigmail tracker, if being handled at all.

Hi @Lambd0x, with Thunderbird having migrated to a different main OpenPGP implementation and Enigmail not supporting old thunderbirds version anymore (in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird) and new GnuPG versions over the last three years. Do you still have problems?

In my understanding, it should be possible to wait for the gpg command pipe from a different process and then terminate the connection on a timeout, kllling the process eventually. So the Enigmail side could implement something. These days I'm not sure what Enigmail uses for OpenPGP support. Thunderbird has moved on to a different implementation and Enigmail stops supporting Thunderbird 68 in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

Enigmail's support for Thunderbird 68 ends in two days:
https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

@rupor-github no problem! :)

@werner I think @Rombobeorn suggests something like

@rupor-github thanks for your explanations and the contribution to the GnuPG and crypto Free Software code base!

There is a user report that got things to work with https://github.com/rupor-github/win-gpg-agent
on https://wald.intevation.org/forum/forum.php?thread_id=2359&forum_id=21&group_id=11

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