Yes I am an admin on the https://pypi.org/project/gpg/ package.

As I assume that many people have HTML emails still turned on, and have no crashes, there probably are more conditions that have to be met to trigger this crash.

Thought about this for a while and rephrased and thus repopened.
I think it would be good to remove or explain the sha1sum checksums in the announcements.
Whether they are replaced by something else, e.g. sha256sum is of lesser importance.

Shouldn't we remove the sha1sum then as well? Or add an explanation?

Reported by https://social.tchncs.de/@duxsco@digitalcourage.social/109546865597565084

The current WKD/WKS draft offers no direct guidance to WKD clients about the type of filtering they should do.

Fixed, to be released with Gpg4win 4.0.5.

@ametzler1 thanks for the feedback!

Or better:

• If it is was broken for you and works now, let us know here.
• if "lists." still is there in email addresses somewhere, please also list.

Thanks!

https://lists.gnupg.org/mailman/listinfo/gnupg-devel has `To post a message to all the list members, send email to gnupg-devel@gnupg.org." now, which seems fine, it was wrong before.

@werner also I suggest to check the default setting for this, see https://www.list.org/mailman-install/customizing.html and you can use the scripts mentioned there to check the configuration of several mailinglists at once and change it, if you know, which one is to blame, e.g. the host_name value.

@werner
Can you take a look at the host_name setting at the [General Options] configuration page for the lists in question,
e.g. https://lists.gnupg.org/mailman/admin/gnupg-devel

As 2.3.7 was released on the 11th of July, see https://lists.gnupg.org/pipermail/gnupg-announce/2022q3/000474.html
I guess that this issue should be closed and some issues moved to one with 2.3.8.

Priorities went off this task for three years now. Is "Release Info" still the right tag?

(Werner just told me that I was mistaken and he needs to take a look. There was a mixup because of the 2018 CVE number.)

I don't see a point in trying to make the fancy curses pinentry work on small terminals.

From my point of view it should be fixed by adding line-breaks to make it work on small terminals. It is better to break the formatting, but allow it, instead of bailing out and leaving the user only with the option to use the more complicated interface. This problem could also affect other password entries where a longer information is displayed.

An alternative to password creation in small terminals could be https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html#Unattended-GPG-key-generation

@LRitzdorf it should work if you enter an acceptable passphrase. (I've just tried with 56x51 widthxheight and it worked)

Not in the way it is used by gpg. See T5880

The current links should be replaced or removed.

One solution is to remove GPA and pinenty-gtk completely, as the used GTK+ version 2 is end-of-life. @aheinecke already asked on https://lists.wald.intevation.org/pipermail/gpg4win-users-en/2022-March/001740.html for reasons to keep GPA. (For which we should make a new issue).

because libexpat does contain vulnerabilties

What are the other to places?

A simple first step would be to install pinentry-gtk only in the GPA variant.

I agree. @cklassen can you make a suggestion?

@TheParanoidProgrammer this looks like a very good and thorough analysis, thanks again!

@TheParanoidProgrammer thanks for investigating further. It is highly appreciated!

@NoSubstitute It is okay for me to keep this issue, if most people prefer it this way, was just asking.

Ah, just seeing that this issue is resolved. Shall we open a new one to be well structured?
(If we reopen this one, there is a lot of old information in here that does not apply anymore before the fixes that went into dirmngr/gnupg).

Does gpg4win ship a TLS library with gpg or does it use a system default?

@ikloecker thanks for the hint (At first it looked like a different defect.)

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

@werner the main issue here, that Hakan has found a usability problem:

We (@hakan-int and myself) saw the problematic behaviour in one setting. It was a VM where Gpg4win had been installed, deinstalled and reinstalled again. We still try to find out how to reliably recreate the situation and what is the difference between a working and a non-working case.

In https://wald.intevation.org/forum/forum.php?thread_id=2395&forum_id=21&group_id=11 "Kim Nilsson on 2022-02-15 16:48" reports that

You may have to restart the dirmngr to see the log-file option be honored. The gpg request to dirmngr should be visible in the log.

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

Ubuntu have been syncing since 7th December: https://www.mail-archive.com/sks-devel@nongnu.org/msg07174.html

Why the Ubuntu server? AFAIU it does not sync with other servers and it has some tained pubkeys (which is both fine as a choice of this service, it just does not seem to fit the purposes best).

@alexnadtoka wrote:

both versions had issues(( and send two requests to RU and EN comunity . No answer for two days already

@alexnadtoka When using Gpg4win-4.0.0 or 3.3.16 with an updated GnuPG the validation of dirmngr works fine with the Let's encrypt certificates again. If you have one of these versions, and you still have problems, you need to be more specific about which connection you are referring to.
Maybe it is best to ask on one of community channels (e.g. the gnupg-users mailinglist, see https://gnupg.org/documentation/mailing-lists.html )

Thanks for creating the issue.

(Ah seems I needed to do any comment, before the inline comment was published at all.)

@ikloecker I've added the following inline comment above (but I am not sure if it was visible, it still says "unsubmitted", whatever that means)
I've also experimentally pressed "raise concern" hoping it would by inline comment visible. Anyway I've meant to only make a suggestion:

This commit changed the behaviour:
https://invent.kde.org/pim/libkleo/-/commit/bf7af017d84747d83ec16e0f8ab03b656899bfcd#c50ded182b9e04dd8e8c34c84c3bfd32ec2c5b46_149_214

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.