So what now? You just updated the m4 files in master yourself and I should remove it here? Way to encourage contributions.

In D545#6031, @bnavigator wrote:

The patch already updates to the current version + the GnuPG specific changes. Make a diff to http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_python_devel.m4;hb=df506ec920751087985f322e9b60d263c828661c and see for yourself.
What did you do additionally?

Wrong button? Didn't mean to abandon

In D545#6028, @ikloecker wrote:

I have updated m4/ax_python_devel.m4 to the current version and changed the call in configure.ac to set optional to true (which this patch didn't do causing the build to fail).

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.

Interesting. I need to look closer at it. I scheduled it for 2.4 but it won't be in the forthcoming 2.4.4. There are still other interesting things on the short list (e.g. timestamping support) but we may do that only in 2.6.

I have updated m4/ax_python_devel.m4 to the current version and changed the call in configure.ac to set optional to true (which this patch didn't do causing the build to fail).

Alright.

Thanks for the report. It comes right in time for the next release. It might already be fixed due to a lot of changes in the pkcs#12 parser.

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.

Looks good except for one thing. There's also a deprecation warning, but let's fix this with the next commit.

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.

Ingo, what do you think?

In T4127#170518, @aheinecke wrote:

With the recent commit the old workaround works reliably again.

What needs to be done that this gets merged?
Having to carry an increasingly large patch for NixOS is not ideal for us and it would be preferred if this could get merged.

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.

Looks simple enough. Shit it!

Ship it!

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.

I can test this. For Ebo I want to try using the flatpack so that she can benefit from Dans work on debian stable, too.

In D573#5989, @nicolasfella wrote:

pinentry-gtk etc presumably need similar treatment, so I'm not sure how much sense it makes to add org.gnupg.pinentry.desktop for pinentry-qt. Should this be org.gnupg.pinentry-qt.desktop instead? Or have one desktop file for all pinentries, which could be problematic for the Exec matching in KWin

I do not think this is a very common usecase. For me regarding CMS file operations it would be more important to implement T2435: gpgsm combined sign and encrypt which I find the most annyoing issue regarding CMS file encryption.

I think this is resolved now.

This is what T6799 this needs to be fixed in general.

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.

I encouraged Eva to create this ticket. While the specific case described here might be fixed in current master, the attachment handling still has issues.

The background for this is that .mime we can treat as as a custom extension for us since no one else that I know uses it but it is a registered extension.