This has been resolved with rOb05416e7bc41

This can be closed now that we have the system wide gnupg configuration.

I'm also getting this same error with GPG4Win 3.1.14.

This works now with 0c1bd9076958e584820fadf997ca7d8a248b6888 but needs more testing before this can be relased. It will probably be part of a Gpg4win-4 beta.

I'd suggest to first try the current version to see whether the bug has been solved.

I think the option you are looking for is "--homedir" with that option on the command line you can redirect where GnuPG looks for options and keys.

@glr thanks for the offer. Right now the number of support requests is low enough that we can handle them during the normal triage.

I removed gnupg from the %AppData% directory and restarted Kleopatra, but I am running into the same permissions issue.

please move away %AppData%\gnupg
it usually expands to c:\users\yourusername\AppData\Roaming\gnupg

Screenshots of the issue are attached.

GnuPG uses the systems locale.

In a discussion we decided that we need a deadline for GnuPG 2.3.0 so that we finally release it.

For support please use one of the community resources (see gpg4win.org) and read the manula (compedium) or one of the hundreds of HOWTO floating in the net.

Hartmut, please read Andre's mail again - we can't do anything about it if Outlook considers an extra delay of 20ms as too slow.

Andre,

thats wrong.
if i disable the Addin, the effect is gone.

Best regards
Hartmut

Von: aheinecke (Andre Heinecke) <noreply@dev.gnupg.org>
Gesendet: Freitag, 11. Dezember 2020 08:35
An: hartmut.jacobi@hotmail.de
Betreff: [Task] [Closed] T5176: Problem with Office 365 GnuPG Outlook addin, Outlook reports not to be primary Mail client

aheinecke closed this task as "Invalid".
aheinecke added a comment.

Hi, you can change the default mail app under systemsettings in windwos 10, this has nothing to do with GpgOL, and the delayed start report, I can't do anything about. Outlook just shows this for any COM Addin to shift the blame, seriously we took 0,02s or 20ms on your system for our initialization. That is reasonably fast.

TASK DETAIL
https://dev.gnupg.org/T5176

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, gnupg, HackyJ, Neurone, ccharabaruk, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

Hi, you can change the default mail app under systemsettings in windwos 10, this has nothing to do with GpgOL, and the delayed start report, I can't do anything about. Outlook just shows this for any COM Addin to shift the blame, seriously we took 0,02s or 20ms on your system for our initialization. That is reasonably fast.

I have reproduced the bug

A backtrace with gdb from migw-w64 results in

I did a fresh install of Gpg4win 3.1.14 and imported my standard pubkey, by using

gpg --locate-key bernhard@intevation.de

on the command line.

Sorry, I can' reproduce thus. What kind of key is causing the crash?

Thank you very much

Select your key in the certificate view, click right, select "Backup Secret keys ...", store to a file. Then copy that file in a secure why (USB stick etc) to the new box, import it there.

And I also did a backport to 2.2 :-) See rGa028f24136a062f55408a5fec84c6d31201b2143

It worked again, attaching the screenshot. Unfortunately had disabled the logging and hence no log info.

Long since resolved.

Ah no, this is about the sending part, where we only encrypt to online validated keys, that is not mitigated at all. Disregard my last comment.

This is resolved with the preview feature in GpgOL-2.4.6 Gpg4win-3.1.12

there was an issue that has been fixed in 3.1.14 which was creating problems / crashes when the home directory of a user had a unicode character in it. So maybe your one user had such a username?

On Debian, please see: /usr/share/doc/g++-mingw-w64-i686-win32/README.Debian

IIUC, the error occurred when Kleo is exiting and a destructor (in libKF5ConfigWidgets) is called with null pointer.

Version 3.1.14 released 2020-11-25
Kleopatra / GnuPG: Unicode home directories are now supported. (T5055)

Will be fixed with 3.1.14

Works, I've tested with Kleopatra.

Removing 2.2 tag because it has been fixed in one of the last releases.

3.1.12 was released on 2020-07-24.

It's fixed in master by T3465: --pinentry-mode loopback with --delete-secret-keys, with new confirmation interaction.
For 2.2, you can use --batch and --yes, see T4667: "gpg: deleting secret key failed: No pinentry" when in --batch mode with --pinentry=loopback.

The "Reliability History" says (in Chinese):

异常代码: c0000005
异常偏移: 0002b6c0

The error code c0000005 is something like SEGV on POSIX, I guess.
It occurred at the address 0002b6c0.

Thanks for the info and my apologies for the regression. Please see my comment on T5045.

I am facing a really similar problem currently in version 3.1.13 (on windows 10)
Although the self-test shows all checks passed. I found out that there is an issue with the cache dir file not being created/loaded.
See:

All right, using the current master a Windows user with a Unicode name (e.g. Ⓐlfred E. Neumann) is now able to use gpg properly. Quite a lot of changes were required and backported to 2.2 will also be some work. More testing is of course required. Note that libassuan needs to be taken from Git until we have done a new release.

@werner , if you would like some help moderating this bug tracker, I don't mind volunteering to do it.

Please understand that this is a bug tracker and not a support line.

Thanks for the quick analysis.

We understand the problem, it's a regression from August. For T4083 we changed an internal function to better work with Windows UTF-16 filenames in preperation to at some point fully support UTF-16 and only use the wide character functions as system calls.
But that broke places where internally the local 8 bit encoding was still used.

I can reproduce this.

Observation:
The umlaut is displayed incorrectly on the command line (cmd.app) when the keybox file is created.
(This may or may not be relevant.)

Hi Zetrick,

Hi Zetrick,

Hi all, I have this issue in Win10 in correct installation. Si I am interested what can I do to repair this issue. GPG is working correctly, but Kleopatra's selfcheck show this issue. Thanks. Portug

That is a version of gpg4win which we don't support or even know about. Please ask at their support site. Sorry.

The name field is marked as optional but it is mandatory. This should be fixed.

Version 2 is a bit too unspecific. Which version of what software are you using. Which OS?

Hi,
I corrected all the accents. I created a PR here https://github.com/gpg/gpg4win/pull/3

Any ideas? Is there any other info needed that could help move this along?

That code in gnupg has not been touched in a very long time so this may be caused by some side effect.

I tried using the portable version it wasnt portable apps, i used it the zip file option from this site, https://portapps.io/app/gnupg-portable/