Fixed in 2.4.4 and 2.2.43 - see above for affected versions.

Closing because we believe things are fixed and our test suite confirms that. Feel free to -reopen in case your own file does not import with 2.4.4.

The test file is now part of our test suite and passes.

We meanwhile have a lot of test cases in our test suite and we see no issue. Closing this bug; feel free to re-open if it is not fixed for your case in 2.4.4.

I did a couple of test on the command line which should be sufficient.

We need to fix 2.2.42 too. This because we backported the responsible patch.

In Gpg4win-4.3.0-beta571 with GnuPG 2.4.4-beta132

>echo test | gpg --sign --default-key F8D51DE0EE16E9B57009B8DE458612006D8E6F0D
gpg: Warning: not using 'F8D51DE0EE16E9B57009B8DE458612006D8E6F0D' as default key: Key expired
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: Unusable secret key
gpg: signing failed: Unusable secret key

In T6481#181779, @gniibe wrote:

Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg
FreeBSD: https://cgit.freebsd.org/ports/tree/security/gnupg

I don't see the patch is applied. Please wait for GnuPG release 2.4.4.

Indeed, openSUSE has applied the patch: https://build.opensuse.org/package/show/openSUSE%3AFactory/gpg2

Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg
FreeBSD: https://cgit.freebsd.org/ports/tree/security/gnupg

Works as expected on openSUSE Tumbleweed with gpg2-2.4.3-4.2.x86_64:

$ gpg2 --version
gpg (GnuPG) 2.4.3
libgcrypt 1.10.3
[...]

In T6481#181724, @gniibe wrote:

i still observe the same behavior:

What do you mean? I can't replicate the behavior described by you, using the GnuPG from the repo, or the one of Debian 2.4.3-2.

i still observe the same behavior:

Thank you for the report.

In T6481#171399, @gniibe wrote:

• It is also possible for GnuPG to keep the behavior of 2.4.0, so that it doesn't confuse EasyPG.
  • This is a possible solution #2: change in master: rG2f872fa68c65: gpg: Report BEGIN_* status before examining the input.
  • But... it is difficult for implementation of GnuPG to guarantee this kind of behavior.

For a while, distributions can apply rG2f872fa68c65 for 2.4 series.

Why the limitation to a single OpenPGP keyserver?

Because otherwise the UI will get confusing if you get the same key
e.g. from multiple keyservers And it is AFAIK a limitation of GnuPG.
We could use a keyserver with a DNS entry again which randomly selects
a keyserver? To avoid always using the same one.

Actually, when having multiple keyservers, the following would work:

My suggestion would be the following:

I renamed the task accoringly.

Oh These are good points

This is not the first time I saw that users are confused by this. My wish would be to change the label of the Group at least to "S/MIME (X509) Directory Services"

Is the lack of display of entries in the listbox proper functionality?

Under "X.509 Directory Services" you can add "key servers" for X.509 certificates (aka CMS certificates, vulgo S/MIME certificates). For OpenPGP only a single OpenPGP server can be entered. The suggestion is the Ubuntu key server because it is/was one of very few reliable key servers.

works in Gpg4win-4.2.1-beta178
Note to self: need to check with "to the second" expiry time, in case this only occurs with summertime

works in Gpg4win-4.2.1-beta178

We tested with Kleopatra:

• Only gpg4win 4.2 is affected (the current version) but 4.1 is not affected.
• No vsd version is affected.

FWIW, I am already working on this.

Currently, there is no support for gpg-agent to keep private key not on disk, but only on memory of gpg-agent. Given the situation,
I think that it is good to:

Tested with 2.4.4 beta and the problem shows only up with the parameter file but not when using --expert-full-gen-key or --quick-gen-key. The problem seems to be that the v5 flag is not enforced when using the parameter file. Thus the key is created as v4 key despite that we want to use v5 for the new x448 keys. It is not a severe bug becuase the key will work anyway using software supporting X448. Will of course be fixed for 2.4.4.

Alright.

Thanks for the report. This is the fun with different code pathes. Obviously the v5 fingerprint needs to be used for the pre-made revocation.

Push the change as rE4a9def77488f: estream: Fix call to string filter for estream-printf..

I see your point: allocating STRINGBUF to make sure nul-terminated string.
The code itself doesn't work well in a test case of tests/t-prinntf.c, because it assumes string filter should be called with NULL for string.

It doesn't actually work as expected on X11. There pinentry uses the NET::KeepAbove window flag to make the pinentry window stay on top of Kleopatra.

Like this:

@@ -1196,10 +1196,25 @@ pr_string (estream_printf_out_t outfnc, void *outfncarg,
    future, when breaking API/ABI is OK, we can change signature of
    gpgrt_string_filter_t to have another argument for precision.  */
   int allow_non_nul_string = (arg->precision >= 0);
+  char *stringbuf = NULL;

We could also pass a nul terminated copy to the filter function in pr_string.

All icons that are available in normal/light mode should now also be available in dark mode.

Thank you for the detailed report. I will look into it.

KF6 KWindowSystem has some convenience API to deal with this: https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/136

Awesome, thanks for the report 👍

Tested this some time ago.

Better don't remove your entire ~/.gnupg - removing the *.lock files after gpgconf -K all is sufficient.

And another note: In KF6 icon inverting happens automatically in ksvg or so, so that we don't need to ship breeze-dark anymore. And there will be a BreezeIcons library including the icons that can be used instead of the RCC file. This means we just need a quick fix for VSD and not a general solution for upstream.

One more data point: breeze-icons installs a copy of all breeze icons that do not exist in breeze-dark in the breeze-dark icons folder. So, with icon files on disk breeze-dark has all icons that breeze has even without using breeze as fallback icon theme. Looks like an oversight that the breeze-dark RCC generated by breeze-icons doesn't include missing breeze icons.

KIconTheme sets the fallback theme name to breeze, but those icons cannot be found because we only load the icon theme RCC for breeze-dark. I think we need to load both RCC files in dark mode. No, that doesn't work.

Possible reason: There's a kleopatra.svg in breeze-icons/icons, but there's none in breeze-icons/icons-dark.

This is due to the changed format of the VERSION file.

https://github.com/vorburger/vorburger.ch-Notes/blob/develop/security/gpg-hangs-on-hostname-change.md