Because I'm just starting with GpgOL: Are we talking about adding links in the "Configure GpgOL" window or are there any other windows? If that is the right window maybe we could add a new tab "FAQ" and add the links there. At first I thought the links could be added to the tab "GpgOL" but there are already many entries and the other tabs don't fit well.

I can't replicate this symptom (gpg1 generated key, no problem after migration).
Could you share the *.key file under private-keys-v1.d?

I think that this commit rG8fd150b05b74: gpg: Remove all support for v3 keys and always create v4-signatures. matters.

Not relevant for Windows, but for the AppImage: Qt's X11 xcb platform plugin depends on libfontconfig and therefore indirectly depends on libexpat. So, at least on Linux X11, pinentry-qt and Kleopatra both load libexpat.

All 4 CVEs are findings related to standard conforming compiler optimizations which OTOH break long standing assumptions on C coding. “Let us show that our compiler produces the fastes code ever and ignore any assumptions coders had made over the last 50 year”.

Right, we are not affected by these CVE because we use only the very basic core in gpg and no higher level functions. At least for GnuPG there will be no update.

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

Do you mean something like this

because libexpat does contain vulnerabilties

gpgol/doc/gpl.texi (line 9)
gpgol/COPYING-ICONS (line 52)

What are the other to places?

And updated scd_validate2.py:

Wrote a pam module which interacts a user for auth:

When I greped for links to the FSF page (grep with string "fsf" I found out that there is one link to https://emailselfdefense.fsf.org/en/infographic.html in line 722 of src/ribbon-callbacks.cpp. Is that the link that was meant?

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

I agree. @cklassen can you make a suggestion?

Thanks for you patches. Most of them applied cleanly despite that I delayed processing them for half a year.

@mieth sorry for the delay. meanwhile I adjusted the ciphersuite of the WKD gateway to include an AES-CBC suite. would be interested if it works now on the setup you tested before.

I think this is because we install pinentry-gtk, too. So we have that GTK dependency.

Thank you for your comment.

Gook luck on Solaris with this suggestion ;-)

Gook luck on Solaris with this suggestion ;-)

For the record, the typical response to "it doesn't work" support requests for keys.o.o still comes down to killall dirmngr.

I write a prototype in Python using pyassuan:

Fix pushed to master. Updated graph:

Reagarding the OpenPGP specs: there is a new draft with LOTS of changes to already agreed upon formats and conducted interop tests. Almost everything we implemented in GnuPG and RNP has had rough consensus in the WG. Minor things like AEAD chunk size were the contested pieces. However, now they want to change everything with the possible outcome of discretization the long established trust in the stability and durability of the PGP data and key format.

Great, thank you very much!

Thanks for notifying. Will be fixed in the next release (mid Apri).