Regading Kyber in GnuPG, there are a couple of open questions. For example whether the implicit lengths used for the key parameters match well with the overall protocol structure. Thus, as soon as we have finished the Libgcrypt part we will address this and implement it in some way. Before we do this we have to do a couple of changes to GnuPG required for FIPS compliance.

Example output:

I just saw that Niibe is already working on the integration of the ML-KEM code into the master branch of libgcrypt. Apparently, this is an entirely new code base. Currently we are working on the integration of our ML-KEM implementation in libgcrypt into GnuPG. But based on what I see now it seems that apparently another approach is planned and already underway for libgcrypt and probably later also for GnuPG. It would be helpful if you could give us a pointer what your exact plans are, this makes it easier for us to direct our efforts in the optimal way.

Fall back to distutils for old Pythons: setuptools for Python 2.7 does not have setuptools.command.build.build

In D545#6037, @ikloecker wrote:

But there *is* a setup.py in lang/python, The .in file is even part of the patch

No, there isn't. There is a setup.py in the build folder, but not in the src folder. I suppose the problem doesn't show on build.opensuse.org because they do in-source builds.

Remove the changes for m4/ax_python_devel.m4 serial 36 commit to master in the meantime.

The patch didn't make the necessary change to configure.ac which makes a missing Python a non-fatal warning instead of an error.

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.