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?

I found some links:
XTerm FAQ:
https://invisible-island.net/xterm/xterm.faq.html
Why not just use TERM set to "xterm"?
https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic
What $TERM should I use?
https://tools.ietf.org/doc/xterm/xterm.faq.html#xterm_terminfo

Ah well, Kleopatra has a GUI to set the keyserver - that is probably easier to use.

Here is James' writeup on the use https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html . For more details please consult the mailing lists and the commit messages.

I think that scenario with TPM emulation would be more generic.
What needs to be done to have TPM emulation? Can you point on some doc about that?

Ich you do not have a working TPM or emulation but the tpm libraries installed run configure with the option

--disable-tpm2d

In T5411#149872, @aheinecke wrote:

Our windows explorer plugin keeps libgpg-error loaded when you install an upgrade. That is why our installer asks for a reboot at the end of the install. You have ignored the reboot and you then get the error.

We have another ticket T5012 for this issue.

Our windows explorer plugin keeps libgpg-error loaded when you install an upgrade. That is why our installer asks for a reboot at the end of the install. You have ignored the reboot and you then get the error.

I had the same issue opening GPA or Kleopatra going from 3.1.14 to 3.1.16 on Windows 10. I don't have Outlook installed.

Thanks for clarification, indeed attempt to decrypt data returns an error afterwards.

Well, while importing you get the warning:

Yes, for migration from GnuPG 2.0 reasons, a batch import delays the key checking (i.e. converting from OpenPGP to GnuPG internal format) to the first use. Thus you don't see an error immediately. But if you encrypt something , you won't be able to decrypt it again:

Thanks, Werner.
During further work on this got another issue:

Thanks. I meanwhile pushed a fix to 2.3 so that a warning is shown if the low bits are set.

Thanks for the replies, this makes things clear. We'll update RNP to correctly set/unset those bits while saving a generated secret key and a way to fix up previously generated keys.

Right, as long as there is only one format in widespread use (based on a long existing 4880bis draft) only this format should go over the wire.
Thus, it is a matter how the key is exported. In cryptography you should never have several options - one clearly defined format is what you want. We have had enough trouble with PGP5 peculiarities but in that case their implementation had more users and thus GnuPG had to work around it. Not good, but there was no standard at all at this time.

@onickolay No sorry needed. It was me, who cannot answer promptly.