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.

Yes we could add that. Okular has this actually. For now we were Happy to go with the system default in the last version :)

This seems to depend on the Platform theme. Under Windows I get the same results as you on linux It works fine with me

Since there are some files that would simply have to be created each time under $GNUPGHOME, I've been thinking a bit more about what sort of approach to take for "fallbacks."

That is simply because your XDG_RUNTIME is set to the same directory gnupg uses. See gnupg/common/homedir.c:_gnupg_socketdir_internal

Funnily enough, runtime sockets already adhere to the XDGBDS somewhat by using $XDG_RUNTIME_DIR/gnupg as their path, while everything else uses strictly $GNUPGHOME or ~/.gnupg with no other alternative. Of course, I completely understand that the priority for this is rather low, but I am still happy to look into providing a patch myself that would add these fallbacks if it would help expedite the whole process.

Portable Apps are a Bad Idea because they bypass important security mechanisms. In any case please tak such discussions to a mailing list and please do not use the bug tracker for this. The audience of bug reports is pretty limited.