I do not think it could cause any harm, if a certificate is re-issued we can adapt and worst case we would ship a very small obsolete intermediate. And it would be just one less of a potential problem when verifying our signature that on this PC at the time the intermediate certificate is not available. Having a self contained chain in the signature is also helpful for scripted verification checks where you would then just need to check that the root CA is trusted and then can check everything offline.
And we take a bit of pride in the fact that we can easily be run on offline systems and there this might actually create a bit of a hassle to get the certificate in there. This would also allow for a more easy verification using osslsigncode itself independent of Microsoft tools.

I don't think that it is a good idea to include the chain. Sometimes certificates are re-issued - they are still valid but signed by another top level cert. The certificate also has the URL from where to fetch the intermediates. Let's close this.

For Kleo I think we have it handled, different subtasks for the Appimage and Gpg4win do not make sense IMO since both rely on the same packaging and I feel confident enough to also update the AppImage. A subtask for Okular will make sense though since Sune already spent some time on it and that way we can keep an eye on it.

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.

Ingo could you add more subtasks here that need to be done? So that we might assign them to Tobias.

This does not need to be checked again for Gpg4win since the installation of this file is generated from the Gpg4win installation script.

I did this. da403fe8e4bbc5701ae1d65dd4b0a7267ab43892

Hi Werner,
after I enabled more detailed logging, I found that the issue is whithin an "old" file what was encyrpted using an outdated key. Somehow the gpg-agent got stuck here while trying to decrypt the file. After removal of the file the issue is gone, thank you for your input!

Are you using the keyboxd - that is, is this a new installation with gpg 2.4.3 or an old installation w/o keyboxd enabled?

I am heavily tending towards tagging this ticket as invalid as it sounds super individual, but I would like to understand the reason. Not sure how to triage this. Maybe lets give it a low.

No, I didn't make any special localization settings or environment variables on my computer. The only multi-lingual use case I have is that I used for some time the spanish version of Microsoft Office.

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

The system language is German, the entire system is a German PC, German keyboard layout etc. Other languages used are English and Spanish.
The system is heavily used with different applications including SW development tools, etc.
Never noticed issues like this, so I am pretty sure it's something special in Kleopatra...

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?

Thank you for the fast response!

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.

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.

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.

Werner said it is ok

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

Raising prio in reaction to some customer feedback

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.

I can at least confirm that in VS-Desktop-3.1.90.300-Beta a file pkg-licenses.txt is included, as mentioned in the about dialog.

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: "

works, VS-Desktop-3.1.90.287-Beta

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.

We don't need that anymore in my opinion if customers do not complain that taskkill is too evil for them.

So the actual killing is now done with c5617e9f2426549cba54cb52f9faf9325f8e2929 we are using custom actions instead of CloseApplication to have more fine grained control when the steps are run. CloseApplication would only run in the main install sequence so basically only the Deferred part, but during an interactive upgrade like what one of our Entry users would do it would not avoid the first failure to kill a running gpg-agent this already would break the RestartManager support.

FWIW, the Fileversion is actually the Git revision in decimal

b) Is explained by the following documentation from: https://wixtoolset.org/docs/v3/howtos/updates/major_upgrade/

a) So with my current test upgrading from one beta to another it actually looks in the manifest and if you look there the beta230 of gnupg:

So with verbose logging /l*v inst.log (note the v) I finally saw the issue. My killing code works just fine.

The whole part with colorschemes and high contrast mode and dark mode I have already tested.

For testing I would take procmon, filter for Kleopatra start Kleopatra from an older version. Save the log, take the current beta277 kleopatra and do the same and compare the number of lines in the log.

Ok closeapplication will not work because:

Note to self.

So some research led me to believe that using taskkill from MSI is not uncommon. But most stackoverflow solutions did not work for me. I have one solution that works, though but that opens a terminal window for each process we try to kill. I don't want to use wscript to avoid that, since an installer that executes visual basic is IMO even more evil then an installer that executes taskkill. Both are not really the MSI way, but while we could fix our processes without a WindowMessage loop to die nicely this will not work for an upgrade to vsd32.

So as a replacement for what we have in Kleopatra this would work.

This works very well. I would like to add some data though about the number of reduced syscalls before resolving this.

So with my ryzen 9 on tumbleweed:

So I tested upgrading from 3.1.26.0 to the current beta and it also did not work.

For a very long time i would have agreed with you. But i now understand the usecase. You misunderstand that feature just like i had. It is not about checksum verification or checking. It is for detecting changes in folder trees so that you know when to reencrypt and update your encrypted archive of that tree. Yes this could be done somewhere else but the usecase is valid for kleopatra.

I would rather like to see the checksum stuff be ripped out of Kleopatra into a simple standalone app. It's complete overkill to start the Kleopatra battleship if the user just wants to calculate or verify a checksum of a downloaded file. The UI of the checksum tool in Kleopatra is anyway still not accessible (T6099: Kleopatra: Make checksum verification accessible). How about we redesign the UI from scratch with accessibility in mind from the start?

The tobias/gpgsum branch in gnupg now contains my implementation of this. Together with the attached patches to kleopatra and libkleo, it can properly handle unicode filenames on windows. I'll put those patches up for review at KDE in the next days.

Hello,
this is a support question since you are not a customer to my knowlege please use https://www.gpg4win.org/community.html

The original issue was to unclear to analyse and it was likely meanwhile fixed. For the other issue see the follow up ticket.

I mean this would also be solved if we did not use qiodevicedataprovider but pass the filenames directly to gpg for single files, too. (can't remember the ticket number) but I don't want to do that right now.

In T6526#177082, @ikloecker wrote:

The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.

That sounds like a solid conclusion. I mean if errno is not set explicitly it is basically undefined which value it is, so maybe some other function set errno to no space left on device in that one case where it "worked".

The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.

I've debugged Eva's problem and I think it's unrelated to the original problem, as it's specific to qt.

works: installed VS-Desktop-3.1.90.246-Beta with

The installation parameter for this is documented in our installation instructions. What is new with the next version is that for all files when you open them after installation of GnuPG VS-Desktop for the very first time you will be asked if Kleopatra should be used and have the option to make this permanent.

As what I see is similar as what Andre saw, I'll describe it here. Please check if this is relevant.
After the above mentioned Ticket was resolved, I tried the exact same encryption in Kleopatra on the same Test-VM.

For sent mails folder there is no solution. The problem is that if the mail never leaves the exchange server it is not converted to a standard compliant PGP/MIME but left in Microsofts internal MAPI format where it looks like this. I think thunderbird has support to fixup a message if the mimetype of the first attachment application/pgp-encrypted. Which reminds me that we need to change the filename of our internal attachment, too to use .mim as an extension. Then you will at least also be able to open such messages on other clients with Kleopatra directly to view the contents of the mail. And a side effect of this might be that Enigmail might then be able to open the mails. If not we would need to talk to enigmail how to solve this.

Hi, thank you so much and sorry for delay.
This beta is working for us perfectly.

works

This is NOT the bug reporting form. You will find the form at https://dev.gnupg.org/maniphest/task/edit/form/5/

Thank you very much, we will try it and let you know
Regards
Lukas

that's really cool :) .. I tested now with a mail whole having the Warning message, I press "Show Mail" and it indeed open .. see the pic.
very nice feature indeed.

Meanwhile, can you please share how to use the new feature "open the mail from the Kleopatra menu" would be nice to test it.

Thanks a lot Andre ... I believe it's solved.