Since I tested this both with valid and invalid filenames on linux and on windows I set this to resolved.

The URL was just wrong for Windows. I added debug output and the results are different:

Yes and I get the same result with PNG files. But calling shell execute with such an url looks strange to me, I will try QUrl::fromLocalFile as we use in Kleopatra.

Is executing a zip file really supposed to work on Windows?

Moving the definition and changing it to the name of the po file worked.

Pretty sure its the translation domain. Thanks! Will try to fix that tomorrow

Or is it an order problem in src/CMakeLists.txt?

add_subdirectory(core)
add_definitions(-DTRANSLATION_DOMAIN=\"libmimetreeparser5\")

Other possible reason: https://api.kde.org/frameworks/ki18n/html/prg_guide.html#before_qapp
Are the action texts initialized statically?

I'm wondering whether this could be caused by a wrong translation domain. We have mimetreeparser.{pot,po,mo}, but in src/CMakeLists.txt we have

add_definitions(-DTRANSLATION_DOMAIN=\"libmimetreeparser5\")

Our own internal function signatures is not necessarily a good refernce. The main objection to all what you list above is the lack of explicit length information. For each uint8_t* there should also be a size_t ...len in my opinion. Otherwise the API will be highly prone to memory access errors.

@fse Thank you for your comment (quick ! :-).

KEYPAIRINFO in 2.2 lacks the algorithm (and the fingerprint time). Kleopatra uses the algorithm to check if the algorithm is allowed in VSD.

115.3.1esr

Yes, there is clearly a problem with the handling of NDEF. I have a fix for that but there are other oddities in that pkcs12 object. Do you have the Firefox version you used to create this?

Well, neither OpenPGP certifcate nor CSR creation from a key on a card is offered for any of the cards I tried.
But that is not only for RSA2048, but for all types of keys.

The changes are best reviewed by a developer to check that I didn't make a mistake when I replaced usage of the canSign, canEncrypt, etc. methods with the new hasSign, hasEncrypt, etc. methods or the corresponding compatibility helpers keyHasSign, etc..

The API that you quote at the end is indeed what is comonly understood as how a KEM functions and is exactly what fits to ML-KEM.