Similarly if you decrypt with a PKI BW card and the mimeviewer there are also no longer problems which again might be related that the internal states where somewhat disturbed by the loop in Kleopatra.

I retested this with the current beta and It works without problems. I somehow suspect that the permanent access loop from Kleopatra caused other Smartcard operations to be canceled. Since the test setup is not really good to reproduce to for Ebo I resolved this myself.

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.

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.

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.

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.

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.

This is very much unrelated to any GnuPG code so I can say this is resolved for Gpg4win, too.

So why not resolved?

For me it is like if you open a save file dialog. You want it to remember where you saved a file the last time you saved it. But if you just browse around and cancel it, it should not store that location.

Assigned to me for testing.

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.

@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.

@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.

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

Let me put this on the 3.2 workboard since we already have the "reports error when canceled" on that workboard and T6566 too depens on this, in fact I am currently working on this even though it was not on the workbaord.

Yes these files are rewritten on every iteration.

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.

@ikloecker I would like your opinion if this should not wait for Qt6 if it is an issue with Qt. I guess "prio low" would anyway mean. "Let us leave this for a while" :)