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
      ^^^^^^^^^^^

Just found out something weird - powershell tells me the default characterset is iso-8859-1
~~~
PS C:\Users\bbs> [System.Text.Encoding]::Default

okay, installed 2.2.29 and tried showkey:

C:\Users\bbs> gpg.exe --show-key D:\bbs_gpg.public.pgp
pub   rsa4096 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid                      Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096 2022-11-06 [E]

https://gpg4win.org/download.html, but there isn't a Gpg4win release with GnuPG 2.2.29. The most recent Gpg4win 3.x has GnuPG 2.2.28. (All releases of Gpg4win 4.x include GnuPG 2.3.x.)

Yes, seems so. In either case, there's nothing we can do anything about since the versions provided by us appear to work correctly.

But it is strange that the version can show the characters correctly - so it can encode and decode to the same output.

On Linux, I also get garbled output for your key:

$ gpg --show-key <bbs_gpg.public.pgp 
pub   rsa4096/67BDA85044042E3B 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid                            Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096/08D7C29E12A34AD2 2022-11-06 [E]

This indicates that the user ID was encoded incorrectly by the gpg included in git when you created the key.

I am not sure if the export is correct - or if you need something else?

If I import the keys into gpgwin it shows up garbled - both in the console version of gpg.exe and Kleopatra, but if I run

gpg.exe -k

With the old gpg version it shows up as:

/c/Users/bbs/.gnupg/pubring.kbx
-------------------------------
pub   rsa4096 2022-11-06 [SC]
      0F20E48DEA9FD7A5626DBA0067BDA85044042E3B
uid           [ultimate] Bjørn Bouet Smith <bjornsmith@gmail.com>
sub   rsa4096 2022-11-06 [E]

This is the key exported with:

gpg.exe --output D:\bbs_gpg.public.pgp --armor --export bjornsmith@gmail.com

In T6289#165411, @ikloecker wrote:

How did you generate the key? On the command line? Which command line did you use? Can you attach the public key to this report?

It seems like gpgwin generates keys where the name are not compatible with each other.

How did you generate the key? On the command line? Which command line did you use? Can you attach the public key to this report?

Also - gpgwin is no better:

So because I use some thing that "almost everyone does not use" - but something that you distribute you do not even want to fix it?

Hi Werner,

An old version is still installed and the libgpg-error-0.dll could not be replaced. Make sure that you deinstalled old gpg4win versions and other gnupg versions. The file version of the DLL shall be 1.46.x.x.

I have over 75 PGP addresses:

That is expected. The export re-encrypts the secret parts to comply with the OpenPGP specs and this includes a salt andf IV and thus the output must be different.

No. And this is out of scope for Kleopatra. You can use existing file sync tools to sync the files in ~/.gnupg. Which files to sync depends on what you want to sync. For details, I suggest to ask on the gnupg-users mailing list.

FWIW, your comments about the autostart script do not match with the running processes. Obviously, the autostart script starts gpg-agent with different command line options than the running process. My conclusion is that the autostart script isn't used. Or maybe it is started, but gpg-agent immediately terminates because it notices that another instance is already running.

If you add an autostart script then you may have to add a corresponding shutdown script as well, e.g. a script running gpgconf --kill all. You cannot expect that daemons, that you start via an autostart script, magically know when they should terminate.

In fact, decent 2.2 versions (>=2.2.21) have the ability to decrypt AEAD packets - this has been implemented exactly for the case that some things get wrong at the user site. But we can't change old versions - we are not the Sirius Computer Corporation. I close this ticket because we can can't do anything if you are not able/willing to update to the latest version of the respective branch. Sorry.

@werner
The setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z2 Z3 Z1 worked!

S9, etc. are short-hand IDs, for the cipher algorithms, digest algorithms, etc. Use showpref instead of pref to get the preference list in human-readable form (AES256, SHA512, etc.) instead of in expert form (cryptic IDs).

Hi @werner
I had missed your earlier post quoted below on using setperf.

Create the keys with gpg 2.2. I'm not aware of such documentation apart from the manual page of GnuPG. And, as I tried to explain, this situation isn't really different from any other software. If you create a document with the newest version of LibreOffice then you cannot expect it to look exactly the same with an older version of LibreOffice. It's your responsibility not to use new features of the new LibreOffice if you still need to use an older version on another machine.

@ikloecker Thanks for the clarification (appreciated).

Backward compatibility means that newer versions work with data created with older versions of a program. What you are asking for is forward compatibility, i.e. you want older versions of a program to work with data created with newer versions of a program. In the extreme that would mean that gpg must not use modern encryption algorithms because old versions of gpg cannot deal with them. It should be obvious that this doesn't make any sense.

@ikloecker thanks for your reply.

In T5886#156407, @TonyBarganski wrote:

2. As things stand right now, someone with a Public key created on gpg version 2.3 on a macOS cannot privately communicate with someone using a Linux server, news group or Linux Desktop.

Use a gpg 2.3 version:

Hi Werner
.
Firstly, let me say how much I appreciate the work you and others do at OpenPG.org! Really.

• No we can't because current GnuPG 2.2 versions are able to decrypt such AEAD data.

1. So, firstly, can we get an error message that states something to that effect AND can also be displayed by Mutt?

Packet 20 is the new AEAD packet which GnuPG 2.3 can generate and does generate if all recipients have new keys generated with such a versions. However, the version of gpg you use now does not support AEAD and thus fails.

Since decryption is broken, I'm raising the priority level of this ticket.
It would be wonderful if someone can take a more detailed look into this problem. :)

Please refer to the open Mutt Bug issue 401 below regarding the troubleshooting we've performed which seems to suggest there *might* be something a skew on the gpg binaries.

Sorry, without detailed output of gpg we can't help you here. This is definitely not a GnuPG bug because too many people are using mutt and gnupg. You should also "set crypt_use_gpgme" -it works far better.

Feel free to ask me by PM if you run into problems (wk at gnupg.org). Two of my colleagues are Vim users and thus have an interest in a well working plugin :-). Thanks.

Enable the setting Create OpenPGP encrypted files with ".pgp" file extensions instead of ".gpg in Kleopatra's Settings.

Rename the file and you are done.

Sure there are logs, see the options log-file and debug in the man pages.
To sign using specific subkey or the main key, use the fingerprint of the key and append an exclamation mark.
For example

I'm pretty sure that the first 3 messages are always decrypted with the first key because the passphrase of the first key is still cached. I don't think you can tell gpg to only use a specific key for decryption. The only way to make sure that gpg does not try to use the first key for decryption is to remove the private key of the first key. Alternatively, clear the cache after using the first key, but gpg might still ask the user for the passphrase of the first key.

That looks like a support question. Please ask on a mailing list for help. Sorry, we can't do individual support here.

Thank you for locating the bug!

Hi gniibe!

Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:

• new keys will be generated with correctly tweaked bits
• using secret key with non-tweaked bits would issue a warning
• CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key

Please ask on a mailing list etc. This is a bug tracker and pnly very few people are reading your report.

Sorry, I just discovered that I had to click on "Save All" in order for the file to be actually stored in the disk and then it works.

Here it goes...

Sure.

And it shows

Thank you so much for your explanation.
I just want to try with older version. Because when I try to run

Thank you for your investigation.

Hi gniibe!

After testing about a dozen different term types and doing some library tracing, it appears to be that any terminfo type for which has_colors() is false (so the start_color code is never called) works correctly.

Hi gniibe!

Another link: http://hea-www.harvard.edu/~fine/opinions/xterm-problems.html

All of my testing has been done while connecting via ssh to my OpenIndiana workstation. I'm using PuTTY 0.76 as my terminal/SSH client.

It appears to you identified the problem really quickly again. If I select the entire screen and paste it, the dialog text is there:

@mooney Just in case when it's color related problem, could you try to cut&paste the text of the screen when pinentry should display a dialog box?