Actually I would like to remove the option to install gpg4win at non-standard places because this is somewhat troublesome. However some users rely on this and thus we better don't remove i.

FWIW: as mentioned in T7452#195891, it might be necessary to manually copy the uninstaller to a temporary directory ({{ tmp_uninstall_exe }}) and call it from there to get a clean uninstall:

- name: Uninstall gpg4win from the registry
  ansible.windows.win_package:
    product_id: 'Gpg4win'
    arguments: /S
    state: absent

From a quick glance at the docs. This looks completely correct. What did this do and what didn't it do?

Please ask on the forum or a mailing list for help.

This looks as if it is resolved. Should I be wrong, you can reopen it.

This seems to have been resolved in 2.4.6 by T7151 or T7160. I don't really remember the details, but at least I don't see anything blocking system shutdown now.

Yes, the fix is included in the Gpg4win 4.3.1.

Was the fix part of a stable release? The beta was 4.2.1b55. Stable download on https://gpg4win.de/ is 4.3.1. Am I correctly assuming, that 4.3.1 includes the fix and this issue here can be closed?

The Libgcrypt version you are using has not been build from git or a released tarballs. Only with a released tarball you would get no suffix. With git bou will see a -betaNNNN suffix.

Use --enable-large-data-tests with configure and go out for a real long lunch

Good idea. Done for master and gnupg24

Right, thanks for the information. Might I suggest printing a warning when --keyring is given?

The --keyring option is deprecated and does not work at all if the keyboxd is used. This is the default for a new GnuPG 2.4 installation.

Reading the original bug report it is clear that this is not a gpg bug but a problem in the Python code. This should only be read as utf-8 if the NOTATION_FLAGS line indicated that this is human readable.

An update FYI

@werner I- think you were a bit quick on the trigger to shut this down.
I had rebooted the machine in between attempts. So your analysis is actually not correct.
Basically you have an issue that something in gpg is using something in a locale that is not installed. I pretty much proved that.
Anywho, I'll leave it to you to work out if you want to bother investigating it further.

I assume the support answers helped, therefore closing this.
In case there is evidence of a bug please give more information and reopen the ticket.

There is no way to recover it?

Sorry, this is not a help line but a bug tracker. If you lost or forgot your password you are screwed up.

I already mentioned the exact same thing in T7004 and this user also used the wiki style of the bug report form at first to report a bug. That is why I took the extraordinary step of blocking him.

Please note that this is a bug tracker and not a general support channel. You would also need to write in English - we can't triage reports written in other languages.

Since there are some files that would simply have to be created each time under $GNUPGHOME, I've been thinking a bit more about what sort of approach to take for "fallbacks."

That is simply because your XDG_RUNTIME is set to the same directory gnupg uses. See gnupg/common/homedir.c:_gnupg_socketdir_internal

Funnily enough, runtime sockets already adhere to the XDGBDS somewhat by using $XDG_RUNTIME_DIR/gnupg as their path, while everything else uses strictly $GNUPGHOME or ~/.gnupg with no other alternative. Of course, I completely understand that the priority for this is rather low, but I am still happy to look into providing a patch myself that would add these fallbacks if it would help expedite the whole process.

Hi, you have "compliance de-vs" in your %APPDATA%\gnupg\gpg.conf. But have installed Gpg4win. The default key pair algorithm of Gpg4win is not VS-NfD compliant, in fact the whole Gpg4win version was not approved for VS-NfD. So just remove that compliance line from your config and everything should be fine. Otherwise the forbidden indicates that you are trying to generate a non-compliant key with a version configured for compliant operation.

gpgconf -X in cdm.exe

1. I use Windows 10 Pro (19045.3996 22H2).
2. I don't use gpg-agent on a remote machine (e.g. over an ssh connection) I'm not capable!
3. I don't understand how to get "gpgconf -X" and "gpgconf -V". Can you explain the procedure better to me?

Please post the output of "gpgconf -X" and "gpgconf -V".

VS-NfD is not a standard but a classification for restricted data. Software used to convey such material needs an official approval and is bound to certain organizational requirements. That is what "VS-NfD konform" says. The community version of gpg4win does not have this approval despite that it is technically the same code as the approved GnuPG VS-Desktop.

Fixed by changing server as noted above.

Thanks for all the help @gniibe.

It should not be removed as I believe it is required to be compliant:

I'm afraid that your particular configuration would cause the problem of the negotiation.

Thanks! We will try this out and update you with the results.

Since 2.2.20 we had these items in the NEWS

i am not the original owner of this bug, but facing the same issue.

May be a still running daemon from another version or a a problem during the first install.

I made a clean install of the system and installed gnupg from sources. Now it works strangely.

Omnikey readers only work properly on Windows because the Windows driver uses proprietary extension to make it work. Better don't use them. In case you want to look at details, add