We use libgcc_s_sjlj-1.dll only for for gpg4win's C++ code which is gpgme's c++ binding and the Qt stuff.

I did a new test and found that if it is a single file regardless of disk size, no error appears, but when there are multiple files in a single encrypted folder with a size greater than 1.5GB, the error occurs. Traverse a directory like Zorvek and Aheinecke wrote would be an optimal solution or at least some alert messsage to be aware of the action no supported.

I have allowed myself to edit this task to more reflect what this is about. Although the error is of course in my opinion more of a bug because it is so bad but I would rather fix it with this feature.

I actually agree that this makes sense. I mean at least Kleo could say: "Hey we have detected 50 files that are encryped in this folder tree, do you really want to decrypt them all?"

Then let's get it in there. It's pretty easy to traverse a directory.

reading your report again: You clicked on a folder and expected that all encrypted files in this folder will be decrypted? That is unfortunately not supported.

I have the same message when i try to decrypt files larger than 1.5GB in size; i atached the report "gpgconf --show-version"

I had a similar issue in Windows 10 too. In my case, the issue occurs only when my home path has non-ASCII characters. After I changed home path it works well.

Can you help me, please?

when I insert: gpg --verify -v Bisq-64bit-1.6.2.exe.asc at the command line (at windows), I get the answer:
gpg: cannot open "Bisq-64bit-1.6.2.exe.asc": No such file or directory
gpg: verify signatures failed: No such file or directory

Please try to verify on the command line (cmd.exe):

I do have the same Problem.
It started about 2 weeks ago.

https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works has

Searching the web "Why UAC is important" finds a lot of explanations https://www.digitalcitizen.life/uac-why-you-should-never-turn-it-off/

I've also suggested 3.1.14, but the changelog for 3.1.15 lists two potential important defects fixed for GPGOL (the empty recipient and the auto-retrieve).

My suggestion would be to just keep using 3.1.14 But yeah there will be a 3.1.16 / 4 Beta soonish.

https://wiki.gnupg.org/Gpg4win/RunAsUser has more explanation about this, and I had to give this to quite a number of people in support. (An improvement to the could be a link to a very good external or official explanation, does somebody know one? I've searched briefly but was not successfull to find strong recommendations by Microsoft.)

gpg4win 3.1 has no full Unicode support. You may try to install the new GnuPG 2.3 version on top of gpg4win to fix this problem or wait until we have releases gpg4win 4 which will come with GnuPG 2.3.

Please tell us more details on how we can replicate your problem. Which Windows version, any non-standard software installed, non-standard installation direcories etc. You may also provide the output of

Yes I agree it makes sense to have this as an explicit setting to cover both use cases.

This really depends on the use case. Some people want to extend the lifetime of their whole key. Others explicitly use a long-lived primary key with short lived subkeys. A possible heuristic for the default behavior to propose to the user would be to check whether the current expiry dates of primary key and subkeys are the same or not. The user could still change this proposed default in the dialog that's anyway shown for the new expiry date.

I noticed when testing the surprising behavior that when I changed the expiry on the primary key (tested with a smartcard) it did not change the explriy on the subkey. I think in the past it must have been different that the subkey did not get the expiry by default.

still actual problem (Gpg4win-3.1.15, Windows 10)

This feature does not use Outlook per se.. It's a problem with Exchange really. An Exchange Add-in would be needed to solve it, an Outlook add-in such as Gpgol can't do anything about it..

Good to hear that it works now.

Admin here. I'm sorry your replies did not make it to this site but somewhere got stuck. So copying them for completeness:

Very strange. Both logs show no error.

Sorry, first log was without API.
This log includes API calls.

Here we go. ;-)

Just drag and drop it into the input field. There is also a little cloud icon that makes this explicit.

Thanks for this very quick reply.

Mmh, all these issues should be fixed with the most recent versions.

I noticed that my windows user folder contains Chinese character, and I rename that into English and seems like kleopatra works fine. GnuPG in cli cannot show Chinese folder name properly, thus I guess that's the reason why kleopatra exits without showing a gui.

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.