I read the documentation (and stackoverflow) as owner we have to close our handle before deleting the file. With FILE_SHARE_DELETE we only ensure that others must live with the fact that we can always delete the file, but since we hold an exclusive READ right (which we gracefully share with others) our handle needs to be closed. So the trick was just to CloseHandle first and then the file could be deleted.

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

New MR: https://invent.kde.org/pim/libkleo/-/merge_requests/61

MR for this: https://invent.kde.org/pim/libkleo/-/merge_requests/60/

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

It might also depends on the file type as I wouldn't be surprised if for example the photo viewer opens the file differently than the text editor.

I tested it and for me the files are not deleted:

Since I have such a test card, I just tested it and the issue is indeed gone.

Oh sorry, no that did slightly not make it in when I created the tarball for the current beta.

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.

No change in VS-Desktop-3.1.90.295-Beta

Works on windows, too. VS-Desktop-3.1.90.295-Beta

works, VS-Desktop-3.1.90.295-Beta

works, VS-Desktop-3.1.90.295-Beta

VS-Desktop-3.1.90.295-Beta: now there is no button any more... So still no learn key possible.

It is now: https://invent.kde.org/pim/kleopatra/-/merge_requests/75
I realized that for Qt6 the include qtextcodec and setIniCodec must be removed. I should probably ifdef them to make merging more painless.

Should work now.

High priority because multiple running dirmngr can cause interesting problems.

Merge request was merged for both MimeTreeParser and MessageLib

I thought I had tested this, too. But apparently I lost track of my versions and did not.

Ah sorry i did not read your two messages that analyzed this correctly before I wrote my comment I had not refreshed the page.

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

Nevermind, I realize the problem since we are in the constructor KAboutData::setApplicationData is set when the constructor returns. So it does not makes sense for us to already call KAboutData::applicationData in this constructor and update it in the constructor only to have it overwritten when the function returns. Wit the constructed KAboutData object. Doing it in a thread works because then the thread is run after the constructor initially set the the application Data.

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().

So this is weird to me to describe. After merging: https://invent.kde.org/pim/kleopatra/-/merge_requests/72 It would no longer use the updated KAboutData from updateAboutDataFromSettings in the loadBackendVersions code. There it would see the original aboutdata and then set that with the added otherText.

We should really fix that quickly.

I guess this was high priority.

ok, done for now.

is now hidden in VS-Desktop-3.1.90.287-Beta

Assigned to me for testing.

I do not see any gpgsm processes appear in the task manager on windows when viewing a .eml file which was smime encrypted with the mimetreeparser.
I guess this is enough to move this to done for VSD

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

I think cancel should not save the settings. A case of "uuuh I clicked something wrong and now I am confused" -> "Cancel" -> "Phew everything back to normal". Is more valid then just looking around, canceling and then coming back later and expecing the same state. I would say this resolved.

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

We always try to update the stub files because meta data of the key material might have changed due to the use on another box. On Windows the file system watch might be triggered by the remove of a key file right before writing it (cf. the usual Windows rename file problem) which is the cause for the loop. The new patches now detect whether a key file actually changed and avoid writing it back to disk.

@ikloecker I suggest giving up on this, I know that it is frustrating but it does not make much sense, it is probably related to some compiler settings / Qt cross compile issue and might be a bug in qt. Just do an old style connect and leave a comment that we will revisit this with Qt6. When VSD 3.2 is our last major release based on Qt5 we should not spend too much time investigating this which might be completely different (or not) with Qt6.

@ikloecker I thought about this some more. Why do we do the READKEY when we could look up the keygrips and see that we already have keys for this. That sounds to me like a simpler fix then changing how gpg-agent behaves here. Although I still think that gpg-agent is in the wrong to just overwrite and potentially delete softkeys here.

Ok since this does not happen with other cards this is definetly a gnupg issue I just checked with a telesec card and the behavior there is different.

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.

@werner I think this question is for you to answer. IMO these files should not be overwritten. I mean they could contain actual secret keys instead of just the shadow keys and then those would be overwritten, right?

Ah no I see the difference here. Instead of connecting to a lambda with no args 96da231f97eff9485f62ab925d81252f5f97fc31 connected to the functions which were used in the old signal / slot syntax. I think the fix might be to explicitly list the args of the quickjob result or to use afunction to handle the keygenresult.

works, VS-Desktop-3.1.90.287-Beta

It does not log failed connections but new style connections are never logged when they fail. Since they can't fail ;-)

Seems T6813 blocks me from testing this. The generate window does not close and even if I abort the window, the generated key is not loaded. It is not selectable even if I remove the filter.

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?

Yes these files are rewritten on every iteration.

The following logs indicate that the file system watcher detects a change of those files and that triggers an update of the keylist and the smart card view. Please check whether those files are indeed rewritten on every iteration.

[9508] org.kde.pim.libkleo: "C:/Users/Andre Heinecke/AppData/Roaming/gnupg/private-keys-v1.d/83DAC0502E57C04D7EEC05847D79429C92EEEC01.key"
[9508] org.kde.pim.libkleo: "C:/Users/Andre Heinecke/AppData/Roaming/gnupg/private-keys-v1.d/FE2E7817335F19F3338EC62086B4D666F6292101.key"
[9508] org.kde.pim.libkleo: "C:/Users/Andre Heinecke/AppData/Roaming/gnupg/private-keys-v1.d/961BF16F4EE095BC36EC5F6339F1BA10A561C0C5.key"
[9508] org.kde.pim.libkleo: "C:/Users/Andre Heinecke/AppData/Roaming/gnupg/private-keys-v1.d/3BE5196862C68A4C7B4C850D552070A0CE772827.key"

Confirmed with two other cards. in the gpg-agent log I also see MARKTRUSTED not supported lines while the card is inserted - this is cause by the loop in Kleo.

works, the .part file is deleted on Windows, too, VS-Desktop-3.1.90.287-Beta

works, VS-Desktop-3.1.90.287-Beta

works, VS-Desktop-3.1.90.287-Beta

I know that there is an issue here that the about data in the option dialog of gpgol that is fixed with afb6ce9ce00538242ac69434f586749217f9f619 but did not make it in the current beta. And since this is also related to the tender version i leave this a bit open for now. I think we also might need to reload the welcomewidget in case the signature verification takes longer then constructing the welcomewidget.

So I tested this with an S/MIME certificate for which the CRL was not available and as described by the original reporter Outlook just froze. And you had to kill it. With the current beta you would get the dialog to encrypt the message anyway but this does not make sense for draft encryption where you can only select your own keys.

The count in procmon for kleopatra.exe when starting Kleopatra returned 26434 in VSD 3.1.26 and only 14026 for Beta-277 in my test.

Merci vielmals. Cherry-picked.

I cherry picked it anyway. See my notes in T6813 I think I will at least workaround that one tomorrow.

Regarding the visibility: If you certify after opening or closing the advanced options, the visibility is remembered, otherwise not.

Thank you for the tool tips!