Current progress left being the qml version for Kalendar and right the QtWidget version for Kleopatra. This still require some work in the QtWidget viewer to display that the message is signed and encrypted

So some more data from 2.4.3. Once unpatched and once with your patch.

One complication comes from the fact that gpgmepp and qgpgme include the global config.h that is generated by configure. This needs to be replaced. I'll attach two files where I grepped for usage of the config.h's #defines (generated on Linux) in lang/cpp and lang/qt. The files probably contain false positives.

I was able to find the Craft blueprint with the CMake build system in my Win VM and pushed it to invent: https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/5e9aae4d006f69657d3612c2fe398c9e5ae69ac0, feel free to use it for inspiration or base for future work, or ignore it completely :). It's probably far from a production-ready CMake script, some years ago I just really really *really* wanted to build KMail on Windows (don't ask why) so I did some unspeakable evils to make it happen. This is one of the better things that came out of it...

With the added MIME types Kleopatra now suggests archive (1).tar.gpg as new file name, at least on Linux. Needs to be checked on Windows.

Merged into master: https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/59 and should be available in Release 23.08.

I had to fix it anyway in order to be able to provide screenshot for the latest blog post about encrypting invitations :)

See T6585 for the 1.21.0 release

Am I correct that the reason for the speed up is that it can use a second CPU's engine. If there is a real performance improvement here, we should add this for example using a --compatibility-flag. This way we can gather experience and eventually make it the default. The compatibility flags won't introduce an API incompatibility.

I found this important to do because the SHA-256 results from your test looked extremly slow.

For comparison here are my benchmark results on the same system. Once on Linux 64 bit and once on W32 and once with W64. All runs are native to exclude any virtualization issues.

Updated the patch:

I see little value in viewing emails in Okular. People often want to reply to emails so they need an email client anyway. Or shall Okular get a composer and save the composed email (of course with signing and encryption) to disk so that people can give their reply to their correspondents on a USB stick because that's more secure than using an email server? I suppose it makes sense for spies. ;-)

Thanks! I thought about that when I saw Werner's change in gpg, but would probably have forgotten to actually change it in Kleopatra.

Yes, this might make sense to have a library for the core parsing / reparsing part and then maybe some widgets in Libkleo that could be used to show the information. So that we could in theory create a small executable that just instantiates a libkleo widget to show a MIME mail and Kleopatra could use that then, too. But for clients like Kalendar which don't necessarily use QWidgets it is porbably better to have this split out.

Note: The gpgsm engine of GpgME supports the offline flag (which maps to --disable-dirmngr) only for keylist operations. gpgsm_import doesn't even have an engine_flags argument.

works, I did not encounter the issue following the description

works. So gpgtar obviously knows about the filenames now, too

as this task is for a technical restructuring task, which is obviously done and works, closing this ticket.

Note that Kleopatra has code that should take care of removing a left-over file. See also T6530#172608.

works, the processes are stopped.
For the removal of the unfinished archive on cancelling encryption see T6584.

I also thought that it might be useful to set the subject as filename (not the mime filename but the encrypted PGP filename)

On the command line:

gpgtar -v --status-fd 2 -er Ted -s -o tt.tar.gpg tiefer_test

leaves a .tar.gpg file behind, too, if

• you kill it with CTRL-C
• if you call it without -s and stop the gpgtar.exe process in the task manager
• if you call it with -s and give the correct password

This does not seem to work as I understood it. Just naively adding a setEncoding(GPGME::MimeEncoding) on the output GPGME Data object resulted in an empty file. So this needs a bit more analysis.

I'm wondering why I don't see something like

org.kde.pim.kleopatra: slotResult Removing output file ... after error or cancel

in the debug output. It should be output whenever the signing and/or encryption job ended with a non-zero error code and the output file exists. (See commit on 22 June).

On Windows the process is stopped but you end up with a too small archive.
If you cancel immediately (presumably as long as the file still has size 0) it is removed, though.

I did a little bit of testing with okular, and it kind of gives similar numbers.

In T6199#172571, @CarlSchwan wrote:

I started working on it. Current progress, I managed to move the mimetreeparser/partmodel from kalendar to libkleo and removed the few akonadi bits.

This will still more work to bring back the massive amount of unit tests. I'm also seriously considering to instead of moving this code to libkleo to instead create a new library with this and then have Kleopatra, kalendar, kube use it (and kmail too in the future but that would require a lot more work).

This is a patch for master (which uses nPth for gpg):

I'm trying to use a thread for computation of hashing. It works, but no performance gain, due to nPth.
I do:

npth_unprotect ();
gcry_md_write (mfx->md, mfx->buf, mfx->written);
npth_protect ();

to expect hashing is done in parallel.

Thanks. Wouldn't that require OpenLDAP on every system with gnupg?

Kleopatra should autodetect email messages if passed on the command line or opened via the file dialog. I think Kleopatra should accept any email even if not encrypted. I'm not so sure whether Kleopatra should become an application that offers its service for any email messages if there are proper MIME types for MIME-encrypted or MIME-signed emails.