I suppose that you installed the latest version of gpg4win. Please state the exact version you installed.

Things are working out nicely and thus I am convinced that we will miss that whooshing sound the deadline would make as it fly by.

@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

Hi,
I tried to do your steps described above, but it works perfectly for me, the help page opens (https://docs.kde.org/stable5/en/pim/kleopatra/index.html), only if I'm connected to the Internet.

Hi, I have the same problem, in Italian Language becouse this is the system language!
Kleopatra 3.1.15 on Windows 10

Thanks for the Gpg4win praise; however we don't have the required resources yet to take this up.

Note: If you want to set this early in your program you need to make sure that there is only one thread running.

We have used this task for more than the usual release info, thus the new title. We will use
T5343 for the 2.3.0 release info.

That is a problem on the macOS side, for example with their PINentry tool. Sorry, we can't help you here.
In any case we won't support a gpg4win version released nearly 4 years ago.

See the release notes for GnuPG 2.2.17 (T4606 first item). You need to import your peer's signature from a different source; e.g. ask them to send you your signed key by mail.

Ingo, as you are currently working on the config dialog, maybe you could also fix this issue on the way.

Well, this is a pure Windows bug. It easily shows up when running dozens of gpgsm processes each importing a different certificate (e.g. using Kleopatra's current importer, which spawns one process per cert). The only possible fix is to close all files before starting a long running operation *and* before locking the files.

@rjh reported a problem with keyboxd from the current 2.3 beta on the ML. This is also a locking problem and _might_ be related to this bug.

This issue has been overlooked when we opened T5175 and T5175 was where all the work was done.

Any idea, what this could be? Misconfiguration from my side?

With the third case it accesses the settings file, but does not write anything.

When does it work and when not:

• It works: if I change columns, column widths, sorting column or window size. Then close Kleopatra and restart it within the same environment (screen size).

Kleopatra running on Linux (Ubuntu 20.10, 21.04; Fedora 34, 35 (rawhide)) does this. Closing Kleopatras window saves columns and column widths as shown (it even works if I change the systemwide used font).
On Windows 10 this does not work. Closing Kleopatra via the windows "Close Button" or by selecting "Close Window" or "Exit" from the main menu settings will not be saved. Opening the window again will show columns as they where after installing (way to small for displaying the dates created and expired and the hash of the key). The sorting column is lost too on Windows, but not Linux.
I am unsure if this bug is triggered by my company setup, or if it exists on any Windows 10 installation.

werner this would really be a bug because we have code in Kleopatra to both save the selected coloumns, their widths and the sorting state.

Merged your fix. Thanks for the contribution. Commit should show up here in a second.

Thanks, I try to keep the README always up to date with the debian depenencies as I find this useful myself without running configure multiple times to find all the dependencies.

No question a list like this is bound to be incomplete, but the argument "the README can only tell about those which we don't expect to be installed on a developer's box" does not seem to apply to the other items already on the list. For instance build-essentials and automake are almost certainly on every developers machine already.

There is a message telling you what is missing. Thus I can not consider this a bug. There are just too many dependencies which are required for cross-compiling that the README can only tell about those which we don't expect to be installed on a developer's box.

I have a fix in a branch here: https://github.com/drichardson/gpg4win/tree/fix-missing-zh-readme

This does not look like a bug report. Please ask on a mailing list for help.

Good morning.

Actually I would be in favor of removing this portable thingy. It is and will always be the worst and most insecure way of using crypto.

Hi,
the accounts are Exchange Accounts in Outlook 2016, getting Data from an Exchange Server 2016.

Thanks for the feedback. I sadly forgot to include the italian translations of GpgOL in the installer. So they will only be part of the next relase.

Problem solved in Gpg4win 3.1.15 version! I think it can be closed!

That says "Interface not supported" when GpgOL is trying to obtain some data from Outlook. AFAIK this can only happen if the server is either not a Microsoft MAPI server like OpenExchange or KOPANO or so. But even these two are known to work.

Maybe it helps:
Here is another log from a user with a similar looking problem, same symptoms:

Thanks for the feedback

Ok, I found the message and tried some opening and clicking around w/o any crashes. But back then I also couldn't reproduce it. Please close the issue. I'll ask for reopening if I ever come across it once more. Thanks for your good work!

I set it to Normal priority. It would be good to find out what exactly is the problem with this key so that we can fix this in kleopatra and handle it.

The about dialog where it tells unknown windows version means it's Gpg4win-3.1.13 (the only version affected by T5056 )

It's version 2

Please let us know your gpg4win version.

Released

I am getting the initial exception again:

That would mean I could remember the exact problem. Can you extract the mail name from my logs? I should still have it...

Reopening this as I have seen such hangs multiple times during testing. When importing multiple keys with Kleopatra at once this can be reproduced sometimes.

Noteworthy changes in Version 3.1.15 (unreleased)

We are hoping to have at least a beta release soon with gcrypt 1.9 that we can put in a Gpg4win-4 beta.

This works with the message class changing. We still need to do it for OpenPGP, too.