Fixed in the according repo. The sentence structure made it easy to just replace the word README with pkg-licenses.txt

Ah, forgot about the license text in the installer, I hope that I can do an easy search and replace.

by default we keep the unlocked secret key limited to this very tiny process (gpg-agent) which only does the secret key operations. That is I think the best decision. It is IMO not really a bottleneck since except for very small data bits the bottleneck is usually the hashing. What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute? And even then are you sure it is not your disk IO that is the bottleneck and it is in fact gpg-agent?

Well this depends of course. If the "Hard work" is the actual signing it depends a ton on your Key. An ECC key will go much quicker then for example RSA4096 but IMO the "Hard work" when signing is the hashing and that is done in parralel for extremely specialized setups you could run multiple gpg-agents in different homedirs with access to the same key.

Thank you very much on behalf of our S/MIME users. This also makes it easier for us in the frontend to show a consistent UI.

One proces per user is normal but the two for ebo-ad are strange. Especially the one with the multiple backslashes. I wonder where that came from. Can you try to find this out? e.g. have taskmanager open while you repeat your test and check when it comes up.

Fyi, Carl already, asked me to include that in our build so I will add this.

I created T6842 for the "Cleaning Kleopatra directories on startup" so that we can close this task once ebo confirms that all is fine. Usually I would close this task myself since I already tested it. But well we have QA now ;-)

Works nicely for me in beta300

I'm quite happy with that now. The only thing left to do would be to benchmark this, but to keep this as a an open task for that seems wrong.

Außerdem kann man das ja konfigurieren 😅

Yeah,.. keep the defaults and don't show them? :) With this screenshot you can send even the most friendly user running away. Monospace won't help there. And using different fonts in the same table is also ugly and monospace for the complete table is a no go for me since users should not look at fingerprints or keyids in this table view.

So this is done now to my liking. I took the pkg-copyright from GNUPG as a baseline at the top and then went through all other packages. It is mostly about licenses though and not about copyright holders, even the license information for some packages was weird to figure out. Let alone the individual copyright holders. So I don't think we can or should say "The list of other copyright holders". I changed that now "For a complete list of licenses see: "

Looks good now

This now works to my liking.

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.

My very simple patch for this would be:

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

The Keyresolver did not allow me to encrypt to an S/MIME cert where the root CA was not in my trustlist.txt that was part of this feature to allow users to encrypt "non vs-nfd compliant" to such untrusted keys, like they would be able to also encrypt to untrusted openpgp keys.

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

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

I am temped to put the VSD-3.2 flag on it and raise prio to high because of strategic reasons... So if someone has a cheap fix for this. Please go for it.

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.