@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 properly.

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

Assuming 4.1.0 means gpg4win - this version is too old. The user should update and re-open the bug with more details if it persists.

The same happens with a very recent 2.4:

$ gpgv --version
gpgv (GnuPG) 2.4.4-beta56
libgcrypt 1.11.0
Copyright (C) 2023 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

That version of gpg is too old that I will look at it.

thanks for your reply
gpg -K
gpg: enabled debug flags: memstat
/home/usernet/.gnupg/pubring.kbx
uid [ absoluta ]
uid [ absoluta ]
ssb cv25519 2022-02-13 [E]
gpg -h
gpg (GnuPG) 2.2.4
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

It is a bit hard for us to decipher the Spanish diagnostics. Before we can try to help you please update to a deent version of gpg and libgcrypt. At least the version for Ubuntu is way too old; Libgcrypt is 5 years old, the current version of the lTS branch is 1.8.10. GnuPG is also 10 years old and in the mean time we have fixed several critical bugs; the current version of this legacy branch is 2.2.41! Note that Ubuntu might have fixed some bugs despit ethe version number - we just can't know.

Hi, thank you so much and sorry for delay.
This beta is working for us perfectly.

Thank you very much, we will try it and let you know
Regards
Lukas

I'm using the standard pinentry provided by Homebrew: https://formulae.brew.sh/formula/pinentry#default

gpg -v -K does not require a pinentry. You can check this by adding debug-pinentry and log-file /some/file to the gpg-agent.conf - you should not see any pinentry invocation.

Please try the following beta: https://files.gpg4win.org/Beta/gpg4win-4.2.1-beta55/gpg4win-4.2.1-beta55.exe This should solve your problem. And if not you can now open the encrypted attachments with Kleopatra and it will show your mail.

Ok and its possible to know, how long its should usually take to make new release ?
Can you tell me more about support contract or when i can find more information about it ?
Regards
Lukas

I guess you need to wait until we do a new release. If your company relies on this software it might be a good idea to enter into a support contract as other do.

i dont get any responce, what is next step in this case.
Regards
Lukas

I am closing this, for now as this issue lacks actionable details, we would need an example mail or debug data. So my intent is just to close it and reopen if the issue still occurs with Gpg4win-4.2.1

Noticed this issue while searching for a different one.
I think this could be fixed with T6686 if it has not already been fixed by a previous change that relaxed the detection of the encrypted message part better.

So by we already have code to handle this problem, we had code for "No body but multipart/mixed" and your message was "empty body but multipart mixed" so I just needed to also check for an empty body and the code worked.

Ah damn, now that I closed this as a duplicate I found that we already have code to handle this problem.

Well the message is content-type multipart/mixed. For GpgOL to investigate the mail it needs to be multipart/signed oder application/encrypted or application/pgp-encrypted. (and some other things) But multipart/mixed is something that we don't take a second look at because this means "unencrypted mail with attachments."

Thank you for the response, @werner! (original reporter here)

thank you, i send you test mail
Regards

Hi, my suspicion with the different tenant is that some middleware of yours is inserting something like "DANGER this could not be Virus Scanned by your super secure and expensive middleware" which then results in the mail beeing multipart/mixed instead of pgp/encrypted in the MIME type. Could you ask your communication partner with the problem to send such a mail to you and with CC to "andre.heinecke@demo.gnupg.com

I was trying to solve it with support, but it was not solved until today, this issue we are facing more thank like 2years.
I guess its need to be solved with more advanced support than classic one.
Regards

Looks more like a support question but feel free to create a sample message, encrypt it to info at gnupg.com (WKD) and attach that message to this report.

This is a support requests. Please consult one of the mailing lists or the gpg4win forum. In case this turned out to actually be a bug, please feel free to reopen it.

The data is indeed corrupt. Check with the sender of that key.
IF you look at the data you will soon notice that one line is longer than the others.

Please ask on the gnupg mailing list for support. In case that turns out to be a real bug, please re-open this bug.

If it were the case, I think that graceful shutdown of the system would need to terminate the client of scdaemon at first.

The root cause might be that the "DEVINFO --watch" command causes ...

I also experienced hang on shutdown with GPG 2.4.1 and bisecting reveals that the first bad commit is rG2ccbcfec121f.

The user tried to sneak in an ad link and he has thus been banned. Here is his probably AI generated comment for documentation:

Thanks for your follwup. Let me remark that it is sufficient to stop all gnupg processes (pkill gpg-agent) and then rename the ~/.gnupg to .gnupg-save-NNNN. This way you have a backup and gpg will create a new ~/.gnupg.

OCB mode (i.e. packet 20) is only used if the keys announce it. Thus only after moving a (private) key from GnuPG to a non-GnuPG compatible implementation you will run into this problem. The compatibility options won't override the preference system.

Thanks for the description; this is good for documentation.

Ooops: You need to put

In T6383#167887, @werner wrote:

You need write access to the usb device (e.g. /dev/bus/usb/001/011) or you install pcscd and put "disable-ccid-driver" into scdaemon.conf.

Okay, gpg2 --card-status is accessible using sudo/su.
But I still don't know why bumping from 2.2.41 to 2.4.0 the use of pcsc-lite + ccid stopped work.

I can't access even trying using root.
pcsc-lite was already installed. I tried using disable-ccid-driver as advised but didn't help, scd.log don't even get written using this option.

You need write access to the usb device (e.g. /dev/bus/usb/001/011) or you install pcscd and put "disable-ccid-driver" into scdaemon.conf.

Sorry, I mistakenly closed this task. I reopen it.

Could it be the case that your implementation actually used those bits to calculate a public key?

Sorry for a bit late follow up. How do you calculate a public key? RNP's crypto backend, Botan, is calculating public key without taking in account bits which should be tweaked. I.e. both tweaked and non-tweaked secret keys would produce the same public key. The same is with decryption. Could it be the case that your implementation actually used those bits to calculate a public key?

In T6356#167325, @gniibe wrote:

The interaction goes back to "Your decision?" after you didn't answer "y/N" to the question of "Do you really...?".
What you are asked is: 1, 2, 3, 4, 5 or m.

So here is a redacted CLI-dump of the exact sequence I'm describing in my post. This is with untweaked keys and gpg 2.2.40 and a factory-reset yubikey.

So in case this was not clear... What I'm describing is very similar to the original description, but it is "inverted" - the untweaked key works flawlessly (import and decryption) except for keytocard. And the tweaked key can't be imported - either "Bad Secret Key" or asking for passphrase.

@onickolay Yes, I have. I have used --check-cv25519-bits and it said that it needs patching. I then did --fix-cv25519-bits and exported the key. Looking at the CV25519 private-key bytes produced by my code and by RNP, I confirmed that they did the exact same transformation.
When trying to re-import the exported key into gpg, I got the "Bad Secret Key" error again

@bigmomma Just for a quick check - did you try to use RNP's CLI command --edit-key --fix-cv25519-bits, as it's not clear from the message?

Hi! I would like to chime in on this issue as I am having some weird problems with a CV25519 sub-key and after stumbling upon this thread, I think it is related to this.
Unfortunately, I can't post the key material here, because it is my actual encryption private-key.

Closing. Not a bug in pinentry. The user ID of the key is encoded incorrectly and pinentry just displays the incorrectly encoded user ID.

It's irrelevant whether you can trick the combination of gpg and PowerShell to show the wrong encoded user ID correctly. The user ID is still encoded wrongly and every standard-compliant implementation of OpenPGP will show garbage when displaying the user ID.

Interestingly enough if I set LC_LCTYPE environment variable in powershell $env:LC_CTYPE = "C.UTF-8" - it behaves correctly and generates UTF-8 encoded names.

Looking at the hexdump of the user ID in the exported (and dearmored) public key this looks like a classic double-encoding problem, i.e. UTF-8 encoded UTF-8:

42 6A C3 83 C2 B8 72 6E
      ^^^^^^^^^^^