One year later, I also did translation work for kleo and libkleo, which are pushed by Andre.
So, closing this task.

Fixed in 2.5.3.

glad it was useful!

Tested with the VSD beta 478. Works

2.2 is end-of-life.
There was one actual typo fix which could be used for master, though. Thanks.

Got a simple fix for this which does two things:

1. Correctly act upon an error from the backup file writing
2. Print a warning note.

In T2169#196673, @werner wrote:

Shall we handle this with additional retry prompts, w/o a timeout? I think this makes sense because creating keys with a backup file and a passphrase is a manual task anyway.

There is a regression due to the regression fix in rGb30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7 (from Dec 24 2015) or some related commits:

@gniibe: Please see gpgme/src/posix-io.c where we have this:

Thank you for your report.

Fixed in rA69069bc63e6b: Remove an declaration for an unused function.

Hm, this might also be relevant in GnuPG's codebase in common/exechelp-posix.c, which contains a copy of the same code (licensed differently).

Also works in VSD-beta-478

Backported for VSD 3.3

Note that that Beta uses a 64 bit Kleopatra but the GnuPG engine was accidentally build for 32 bit. This will be fixed with the next Beta. That might increase the confusion a bit.

GpgEX requires/uses Kleopatra so that only GnuPG would be left if you could deselect Kleopatra. And that's exactly what the simple installer installs because the simple installer is included in the Gpg4win installer.

FYI usually these are my install options:

No problem. I can stay on 4.4.x. Just thought I should give the beta a try and let you guys know.

Thanks for your feedback. Maybe the "minimal" install is missing a file. It's a beta version for a reason. We'll make sure to fix it for the stable release.

None. I just use the command line tools and always perform a "minimal" install. @aheinecke: I already tested it on cmd.exe. Same result. Also I do not have QT installed, or a QT_PLUGIN_PATH set up. The bottom line for me is still:

Change the encryption code to only allow 256 bit session keys with Kyber regardless of the preferences, iff --require-pqc-encryption is set. […] We could as well also encforce AES-256 also without that option.

What if we encrypt to several recipients, only some of them having a Kyber encryption key? Should we still enforce AES-256 in that case regardless of the preferences, and assume that by now everybody should support AES-256?

Love it! I think I am going to use “post-heffalump crypto” from now on. :D

But keep https://www.cs.auckland.ac.nz/~pgut001/pubs/heffalump_crypto.pdf in mind ;-)

I wrote it with PQC security level in mind which requires AES256 for the session key as well.

That is what I expected. Meanwhile I re-read the code and history and can tell that the comment is not correct. I wrote it with PQC security level in mind which requires AES256 for the session key as well. However, during the migration phase and as long as --require-pqc-encryption is not enable we should allow an AES-128 session key. This is for the rare case that encryption is also done for non pqc keys which don't have the AES-256 capability set.

Here you are:

At gnupg/g10/pubkey-enc.c you will find

I have replaced the expiring test key with a new non-expiring test key.

Users landing here looking for help.

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

Thank you. Fixed in: rPb415f3108921: build: Fix warning about obsolete pinentry-emacs.

What components of Gpg4win other than GnuPG do you use?

Yes, that's by design. GnuPG is always installed in $INSTDIR\..\GnuPG by the gpg4win installer.

Yeah that is a messed up environment mixing elf and windows binaries. There is no which on windows. It is called where. So if your terminal is able to execute which then this is some kind of Linux environment on Windows. The winpty error comes from the terminal. Please use cmd.exe for all tests.

I just tried to call pinentry directly on Windows cmd prompt:

Works. Tested with VS-Desktop-3.2.94.474-Beta and Gpg4win 4.4

Thanks for the comments. This is a regular git for Windows install which afaik uses mingw64. The messup with the binaries brought in by git has always been this way. I am using aliases to differentiate between the different versions. One might think that this may cause things to break, however all used to work well with 4.x versions.

gpg: [stdin]: clear-sign failed: No pinentrysrc/libwinpty/winpty.cc, line 924

Here you are:

This problem has gone in libgpg-error 1.51, since the implementation doesn't use environ any more.

Installing language-pack-tr-base fixed the issue. Closing. Sorry for the noise.

In T7454#196228, @werner wrote:

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

LANGUAGE= LANG= LC_MESSAGES=de_DE gpg

Thus this should work. But it did only work when I used

LANGUAGE= LANG= LC_MESSAGES=de_DE.UTF8 gpg

Thus the whole thing is related to the configuration of locale.alias and on whether LANGUAGE is set in the environment (for me it is set to en_US:en

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

I can replicate this. A quick strace with LC_MESSAGES=de_DE shows (gnupg master)

Another data point:

$ locale
LANG=de_DE.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Are you sure that the translations for gnupg are installed? On Tumbleweed translations are usually in a separate package. After installing the gpg2-lang package I get this when I force the Turkish translation:

$ LANGUAGE=tr_TR gpg --version
gpg (GnuPG) 2.5.2
libgcrypt 1.11.0
Copyright (C) 2024 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.

In T7454#196094, @werner wrote:

Does

gpg --version

show English or Turkish strings?

I had T3840 assigned to me related to the Qt parts. I close that now as duplicate. But I don't see that we ever added a call of gpgrt_w32_override_locale to kleopatra or gpgol either. Which I assume to be the fix for T7454

There won't be improvements to PGP/Inline

The status of HTML Mails is noted in T6333 everything else here does no longer apply afaik. Although mailstore has since been known as an incompatible addin.

I have fixed this as a7349189f3af05822eba4bd17b62482fa2b0747f so I am closing this as a duplicate of T5982 because it is clear to me now that the last remaining and current problem was sending and not receiving such mails and was broken by 9f81ed6561c5f41e50d1a51333c9586a33ed2ef6