Does not work in Gpg4win-4.2.1-beta178

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

For what it's worth when I filed the Debian bug I mistakenly believed min-rsa-key-length in gpg would do that but it only applies to de-vs compliance profile and is *silently* ignored otherwise.

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:

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;