@dvratil cool, I'm looking forward to it!

in our study we've found that personal users often did not know that their software is capable of sending encrypted email. I blieve that most of them want a protected communication by default. (I may have seen surveys about this at some time as well.) If the recipient has published their public key, they are indicating that they can receive encrypted email.

Linked from https://wiki.gnupg.org/EMailClients/KMail

Saving an attached messaged (in mbox format) is something that I sometimes want. It should be okay to implement.

it would break the verification of too many signatures.

The default time period for warning about pubkey expiration is 14 days in the old Kontact (IIRC).

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.