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

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

Sorry for resurrecting the done task, but I got a message from @pmgdeb who noticed there is mismatch between parenthesis in the --with-fips-module-version help string. The attached patch fixes the issue and add proper help text.

I am tending towards wontfix. The reason is here that the sender attempts to send HTML with inline pgp. Which is not supported. Then that HTML apparently tries to be mutlipart/related which is not supported for inline PGP. Then it would require us to correct a wrongly sent content type of the inline attachment so that outlook does not interpret it as a png. And in that Format it could even be that Attachment1.pgp is not encrypted but instead png data, as the content type indicates.

For the next release I'll change the gnupg.net mappings to use the Ubuntu server also for non-TLS connections.

I have just checked both the installation script, which still installs gpgme-json.exe and the gpg4win-4 installer downloaded from gpg4win.org gpgme-json.exe is properly installed under <instdir>\bin gpgme-json.exe and under bin_64

See T5758. The workaround is not to set a reader-port.

Downgraded the gnupg to 2.2.33 using this installer and I am now able to successfully open the Kleopatra GUI.

Should also note that once the GUI is opened, GnuPG's smartcard deamon (32 bit) transitions to Very high power usage and appears stuck there, consuming a full logical core's worth of CPU time.

Now, unwrapping supports both cases (KW and KWP).

For unwrapping, it is good if we can support "automatic" unwrapping, apply W^-1 and check the first 8 octets to see if it's KW or KWP.

Thanks. Looks good to me (both merged changes and the above proposal). In addition to the changes proposed above, we certainly need to update the documentation about this, probably also the FSM diagram.

The problem was the error handling.
I didn't apply the patch directly, but improved the code paths.

And I'm testing following:

The "at first" change done.