As far as I can tell, the sizeHint is "correct", for the items that are currently in the combobox. At the point in time of creating the dialog, the combobox only contains two items ("new key" and "no key"), which both have shorter strings than an average key description. The actual keys are only added to the combobox at a later point. I tried to make the dialog's size update when that happens, but have not managed to get it working yet, i think that some cache is not being invalidated correctly.

I'm not sure if a proxy model is the best idea to explode the keys into user IDs. In particular, exploding the user IDs after filtering the keys sounds wrong because you would have to put another filter proxy on top to filter the user IDs. It might make more sense to have a proper model with all user IDs and then filter for primary user IDs if only those are needed.

I don't think that it is a good idea to include the chain. Sometimes certificates are re-issued - they are still valid but signed by another top level cert. The certificate also has the URL from where to fetch the intermediates. Let's close this.

Werner and Tobias are both correct. If a new subkey is generated from scratch then gpg uses the current time as key creation time and sets the expiration date (in the internal in-memory representation of a public key) to the key creation time plus the expiration value.

Sorry, I should have been more precise in my description of the problem. Specifically with --quick-addkey, gpg's behavior seems to be that the expiration, when given using seconds=... is treated as seconds from now.

FWIW, when updating the expiration time gpg does this:

My explanation of gpgme's behavior was not quite correct: Specifically in the QGpgMEQuickJobs for creating (sub)keys, the API uses QDateTimes, which are then converted to seconds since epoch.

That's both not correct. gpg takes the expiration time in seconds since creation time. For a new key this is close to the corrent time but not really. For an prolonging an expiration, this is of course different - the creation time of the key needs to be taken in account. I recall that we once had a discussion and agreed to keep it at time after the creation of the key. This avoids problems with the expiration going negative.

In gpg you may also specify the 4xpiarion date in ISO format. afaic, gpgme supports this.

Sorry for the fallout and thank you for taking care of it.

File dialogs
Code does use the standard Qt File dialog, but I_think I should redo it to use the static methods instead because that let the backend take over.

First start wizard

There is lot of separate things in here. I'll do a couple of different comments per thing

The main window including the "Loading certificates..." overlay is shown again while Kleopatra fills the key cache.

works with Gpg4win-4.2.0

For Kleo I think we have it handled, different subtasks for the Appimage and Gpg4win do not make sense IMO since both rely on the same packaging and I feel confident enough to also update the AppImage. A subtask for Okular will make sense though since Sune already spent some time on it and that way we can keep an eye on it.

At the moment, I don't see any subtasks to add unless we want to have separate tasks for gpg4win and the appimage. It's just a matter of updating all packages to Qt 6 and the KDE packages from the beta release, add new dependencies, check/update all patches. Other possible subtasks could be kleopatra and okular.

We could also use this for T6874: Kleopatra subkey management improvements

Ingo could you add more subtasks here that need to be done? So that we might assign them to Tobias.

Ah... it fails by make check because it does change the text in tests/basic.c which requires update of hash value.
I'm going to take care of this regressions.

Tobias could you create an MR for this?

This does not need to be checked again for Gpg4win since the installation of this file is generated from the Gpg4win installation script.

I think we should not fix this issue because T6846: Kleopatra: learn TCOS cards automatically replaces it. If we don't have a Load certificates button anymore we also don't need a better progress for it.

I am moving this back to WIP (my assignment to QA was wrong) since this is only done for me when the translations are accepted / commited in Kleopatra upstream so I can drop the patch.

Should be fixed for the next release.

Checking if the key is not otherwise used is unrelated and should be a diifferent Task since this also relates to OpenPGP. For me this Task is about creating a similar API for gpgsm (--delete-secret-key) that we have for OpenPGP.

Thank you. All applied and pushed to master.

In 2.4, a user need to specify disable-ccid in scdaemon.conf when scdaemon is built with integrated CCID driver (using libusb) but the user wants to use PC/SC driver instead.

As it is so complicated to check all possibilities:

Searching by keygrip is actually fast with keyboxd.