Go ahead and split it of, then. And setting a key to disabled in Kleopatra itself is not that urgent that it has to be in vsd33.

I think Kleopatra now respects the "disabled" state of OpenPGP certificates. I don't remember the outcome of our discussion about allowing to disable OpenPGP certificates from Kleopatra, but I think this should be split out of this ticket.

Was anything done here apart from en-/decoding filenames to/from UTF-8 on Windows?

I disabled this for offline keys because I erroneously assumed that one would need the primary key for changing the password. We can simply replace the check for the primary secret key with a check for any secret subkey that's stored on disk.

Along with the monitor we should also implement a domain selection feature.

Another important use-case is to provide a way to migrate to a newer smartcard.

Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.

I had wrong interpretation about symmetric cipher algorithm identifier in the draft. It specifies symmetric cipher for the following Symmetrically Encrypted Data Packet (I was wrongly interpret as if it were specifying algo for AES keywrap).

"Today" was already removed together with other changes for T6621: Kleopatra: Remove "in n days/weeks/months/years" input from Change Validity Period dialog.

I merged the change by Werner to get the value from frontend.

In the current code, just for testing against the test vector in m https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-02, there are specific value in the key combiner KDF.
Namely, the value 105 for fixedInfo is defined in the draft (and it will be changed).

I created a pubkey (actually a subkey) for your above test keys:

I use this for testing:

With Gpg4win-4.3.1 I consider this solved:

On March 11 and 18, the private key file DE1AB1D22899CEC7DBB1A7863F34E6E92BFB7756.key was wrong.
I updated on March 25. Now, the endian is GnuPG (d is big endian).

Thank you!

See T7046 for the release info. Note that the mentioned fix for kwallet already landed.

I extracted data from https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-02 and compose x25519 key and MLKEM768 key. Here they are.
x25519 :

I still need to land the fix for the kwallet problem, but that can be done first thing monday so nothing that really blocks a release

I had a look at the open tasks for pinentry(-qt) and didn't see anything that we should address before doing a release. @werner?

I should say: I can ship a snapshot in Gentoo if that's okay, but I'd prefer not to.

As a first experiment, let us use CIPHERTEXT in the format of (enc-val(ecdh(s%m)(e%m)(k%m))) (s: encrypted-session-key, e: ecc ephemeral key, k: kyber ephemeral key).

So after taking this down to where it was only patching status.h and mainproc.c to add a write_status_output() I realized the whole issue is down to status-codes.h not being updated automatically if you apply a patch to status.h in a released version.

Having looked at the build log again after applying the patch, I see the first test failing is

Oh wow. It seems you have already coded the feature request. I didn't want to generate work for you and offered to submit a patch. Not that I am complaining.;-) Thank you!

Those options where originally intended for debugging but your suggestion makes sense. I also add this to most other tools.

The patch is part of 1.7 - please test and in case of problems feel free to re-open.

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.