Lets make sure that we look into this for 3.3

can be tested with beta312

Damn this actually happens with every file with a space. Why didn't our Gpg4win users,.. report this. 😐 I checked T6056 was part of the last Gpg4win release...

Our current PKCS#15 widget is optimized for RSCS cards.

@ebo if tasks have a parent please directly assign them the same priority.

This looks very similar to https://bugreports.qt.io/browse/QTBUG-85744 for me nearly all emojis work except the frowning face please do not investigate the font / emoji issue further.

The numbers in this dialog come from system font setting for monospace fonts and that might be broken for you. But you should then have problems in other applications, too. There is nothing special here and it works for all our other users.

I am closing this as resolved for now. I would need a completely new client or mess with the registry keys in which outlook stores the performance data to test this. But I would bet it still lists us as responsible for the slow start of outlook. But the time it will then show should now be 0ms since we absolutely do nothing anymore in our DLLMain.

I don't really know how to test this though since it tracks this over time and history. Let us see if my change fixes this, It may be that outlook does not measure the DLLMain (which I am pretty sure it does) but the actual COM initialization, in which case my change did nothing. But I don't see any way in which my change could make things worse.

I think outlook shows any native addin there. As you can see by the empty bar we don't really do anything in there to slow it down. But let me check if I can move the extremely little code we have in there somewhere else.

Oh, the user is actually asked with this? I wonder if that is something that is new now, I think so. I mean its been quite a long time that we added support for embedded filenames but 3.1.26 was also long ago.

In GpgOL at least I have an API call to query the display language of outlook. I just need to pass it through to gpgme early and forgot about it. Also I don't think this would actually help completely if gpg-agent is running already.

fixed in beta302

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.