I was referring to your comment earlier in this very issue:

Where do you find a statement that --keyring is deprecated? I planned to to remove it with 2.1 but there were too many requests to keep it and live with the problems of multiple keyrings. Thus the option stayed, it is just so that in addition to pubring.gpg and pubring.gpg we now also have the option for keyboxd - which is the default for new installations.

I'm not going to keep re-opening a ticket that you keep closing. So i'm just going to state here what i believe to be the upstream intent is. If you think this is wrong, i'd love a clarification. I believe that "deprecated" means that the GnuPG project believes that an option or configuration choice should not be used, and will eventually go away.

That is an installation/migration question and the warning is just a convenience thing to remind the few early users of keyboxd to migrate to common.conf.

As usual use ./deadbeef.... as the filename to distinguish it from a fingerprint.

I understand you as saying you won't fix the fact that the warning is not emitted during initial homedir setup. I'm not sure why that scenario is not worthy of a warning when a post-setup scenario is, but okay.

Won't be fixed for the creation thing.

This warning doesn't seem to be complete; no such warning is produced on the first run of gpg. For example (with no ~/.gnupg):

The wonders of Windows! Who knows which overzealous component of Windows deleted this file. I suspect that your virus scanner wrongly suspected the file to be malicious (false positive) and removed it. Kleopatra certainly doesn't delete any of its files itself unless you uninstall it. Since a reinstallation (as proposed by Windows likely because vanishing files is a common problem on Windows) solved your problem I'll close this ticket as resolved.

Users landing here looking for help.

This looks like a bug with gnutls which is the only tool that fails :

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.