I suggest to replace size.width() with qMax(size.width(), minWidth) where minWidth is the width of a reasonably sized text (to account for different text sizes) instead of trying to fight with the combo box. Combo boxes are not a good UI element for long entries.

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.

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.

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

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.

I haven't looked into it and I think this has really low priority. I'm pretty sure it's a problem with a the out-of-correct-order destruction of (static?) objects on shutdown. If I remember correctly then it is triggered by the DeviceInfoWatcher.

Re-opening to address the missing "Loading certificates ..." overlay.

gpg's output indicates that gpg exits on the first invalid signature. This cannot be changed by Kleopatra. And I think it's irrelevant whether there are valid signatures if one signature is invalid. If you have a contract signed by multiple people then the contract won't be valid because two of three signatures are valid.

If no (OpenPGP) key servers (i.e. set to "none") and no (S/MIME) directory servers are configured then the lookup only allows queries for email addresses. Otherwise, any query with at least one non-whitespace character is allowed.

I had a quick look at "Lookup on Server" with regard to doing WKD even if no key servers (neither for OpenPGP nor for S/MIME) are configured. This requires more work because WKD lookup is only possible if an email address is entered while key server lookup also works for arbitrary search terms. The users have to be informed about this restriction which is out of scope of this ticket. I think this fits nicely into T6493.

In T6761#179919, @ebo wrote:

This is not as intended. When doing a search, we wanted No error message and only WKD search should be executed.

The following operations were changed:

• Export OpenPGP key to key server now shows an error if key server is set to "none".
• Refresh OpenPGP keys now shows an error if key server is set to "none".
• If key server is set to "none" and no S/MIME directory servers are configured then you'll get an error when you try Lookup on Server.
• Kleopatra no longer stores the special value "none" as "hkps://none".

The fallback wasn't used/offered for any GnuPG versions after 2.1.19.

What if the second signer cannot verify the first signature because they don't have the required public key?

Use same priority as T6761

Fixed.

Fixed. This regression was introduced with the fix for T5697: Kleopatra: Crashes or hangs on circular certificate chains.

Which certificate list? The list in the main view? Or the certificate list of a smart card?

I think it's something special in Kleopatra in combination with your system. Kleopatra is deployed on loads of computers in Germany and you are the first one to report this problem. I understand that you do software development. Did you maybe set some localization settings or environment variables to test/debug things you develop? Can you try some other KDE application, e.g. Kate? You can get it from the Microsoft Store or alternatively at https://binary-factory.kde.org/job/Kate_Release_win64/.

To me this looks more like a ki18n/Qt issue than a font issue. In particular, the key size drop down doesn't use a monospace font. The code uses the default locale to localize the number representation. What's the system language of your Windows?

For S/MIME archives we still use the old code. gpgtar doesn't even support gpgsm.

Looks like a missing unescaping somewhere in gpgme.

This is related to T6373. If T6373 is fixed, then we should get KIO's standard file conflict resolution dialog automatically. On Linux, you should already get the dialog which allows renaming the output file.

On Linux, gpgme already passes the locale (set with gpgme_set_locale) to gpg which should pass it with every session to gpg-agent. No idea if this also happens on Windows because there are some ifdef's. The gpgme documentation mentions that the locale should be set immediately after gpgme has been initialized and that gpgme doesn't do it itself because it wouldn't be thread safe.

Currently, the "Loading certificates" window is shown as long as gpgsm --learn-card runs. Instead of showing this window longer we should probably add some general progress indicator to the smart card view (e.g. in a status bar), so that the users see that Kleopatra is updating/loading information from the smart cards.

Some technical details:

• KDE's ki18n uses the LANGUAGE variable to set/get the language to use. On Unix, we simply use QLocale::system(), but on Windows and macOS we look directly at the LANGUAGE variable because Qt ignores this variable on those systems. See https://invent.kde.org/frameworks/ki18n/-/blob/kf5/src/i18n/main.cpp#L63
• KDE's kxmlgui reads the application-specific override language from the file QStandardPaths::GenericConfigLocation + "/klanguageoverridesrc" and sets the LANGUAGE variable accordingly (which is then picked up by ki18n). Example from my system:

[Language]
kmymoney=@ByteArray(de)

Regarding the format, =de would probably also work.
See https://invent.kde.org/frameworks/kxmlgui/-/blob/kf5/src/kswitchlanguagedialog_p.cpp#L64

assuan_pipe_connect, etc., is outside of my comfort zone. Somebody else (@werner ?) should check how to prevent two gpgsm's started via gpgconf --launch and assuan_pipe_connect (if that's what happens).

I guess that the second instance is started by gpgsm_new (engine-gpgsm.c) via assuan_pipe_connect.

The "Load Certificates" button still remains greyed out if nothing changed, i.e. if no new certificates could be loaded from the card. This could be changed, but pressing "Load Certificates" multiple times won't magically fix loading the broken certificates.

Should really work now.

Looks like ReaderStatusThread assumes that the data for the card didn't change. Therefore the card view is not updated (as before the changes for this issue).

In T6839#179343, @aheinecke wrote:

Wait,.. I misunderstood this issue B81CE112B26A8EA8BE7B95D2E375339BF4C51840 has no encryption subkey o.O

Or you use a Cleaner like the one I added to QGpgME: https://dev.gnupg.org/rM278f92b189ece58dee2036450ac029e3599fdb1f

Now the Learn Certificates button is shown if at least one card key is unknown. And the list of certificates is shown if at least one certificate of a card key is known.

Should work now.

High priority because multiple running dirmngr can cause interesting problems.

Sorry, I didn't really pay enough attention when I reviewed this, but I thought you had tested this.

updateAboutDataFromSettings is calling the static KAboutData::applicationData() and KAboutData::setApplicationData() from the c'tor of AboutData, i.e. before the AboutData has been fully constructed and has actually been set by the setApplicationData() call in main(). And then the call in main() overwrites the application data set by updateAboutDataFromSettings. Before the change it worked because the thread called updateAboutDataFromSettings after the application data had been set in main().

You are right. Forget what I wrote. I had forgotten that the Windows CI images use Craft to install the non-KDE dependencies.

It may make more sense to add the Craft Windows job instead of the Windows CI job because the latter doesn't use Craft, so that everything you did for Craft doesn't help with the Windows CI.

I guess this was high priority.

We don't change settings. We just remember what the user used the last time. That we save this information in the same file as settings doesn't make them settings. (It might be more correct to save last used keys/options in the state file where window sizes are saved since some time to better separate this information from actual settings.)

I have added a workaround and tested it on Windows. Works now for me, including T6566.

Looks like Werner fixed this by avoiding unnecessary file changes in the agent.

In T6584#179021, @ebo wrote:

(It takes maybe 10 second before the file disappears when you hit F5 in the explorer)

And it's the signals that are not found. I don't see any indication that this has anything to do with the slots/lambdas.

Well, the failed new style connects are logged for me with "QObject::connect: signal not found in QGpgME::QGpgMEQuickJob". I haven't dug into how the check works for those connects. It turns out that none of the three connects to the signals of QuickJob work (two of those connects are done in ProgressDialog). Even the connect to the argument-less done() signal. So this has nothing to do with default arguments. This is very disturbing because this means that any other connect might also be broken.

Okay. How do we fix this? Make gpg-agent not rewrite the files again and again if nothing changed? Stop watching the private key files for changes and then miss updates in Kleopatra causing weird update problems like T5546: Kleopatra: After importing the first pubkey for a card from LDAP the keylistview is not refreshed for which I have introduced watching of the private key files?