I had a look at this. gpg emits the following status messages:

[GNUPG:] UNEXPECTED 0<LF>
[GNUPG:] FAILURE decrypt 38<LF>

@ikloecker I think your logs contain only false positives, I do not know that we use any defines created by config.h. Maybe for gpgme_off_t but even so when I moved gpgme++ and qgpgme from kdepimlibs into the GPGME repo I did not add any defines to configure for that.

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

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

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

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 ran the test AES.OCB encrypt only, no compression test with the same GnuPG 2.4 version on Linux.

This works.

When the output parameter is given it might even clean up a temporary file on error, but it might also not so we should make sure on a higher level that we check for that and remove it when gpgtar crashes or something like that.

Due to the double fork in gpgme we won't get the exit code which gpgtar emits. Possible actions in a signal handler are also limited; in particular we can't use stdio or estream. The only option to print a status line would we by using write directly. However, this might mess with the libassuan buffering. Thus, it is not a good idea to pkill gpgtar. Same is true for gpg and gpgsm.

ready for testing

Done. Can be tested and closed with T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.

And of course we also need to adjust GPGME

I'm reopening this. Its probably not a regression but I was sure that we had progress for large files fixed in the past.

Yeah no progress for files larger then 32 bit o.O... But this used to work 😭

On 64 bit linux this works btw. so I think it comes down to the difference between 32 bit off_t and 64 bit off_t

Yeah, its the ugly off_t again. I am just testing how this works with single files above that threshold we worked quite a bit on this back in the days https://dev.gnupg.org/T2368

Yeah, probably a Windows/MinGW 32-bit problem. GpgME::Data does

off_t size = seek(0, SEEK_END);
seek(0, SEEK_SET);
std::string sizestr = std::to_string(size);
// Ignore errors as this is optional
gpgme_data_set_flag(d->data, "size-hint", sizestr.c_str());

Probably some issue with large files / integer overflow. I am testing on Windows with 32 bit.

Mh, let me check where the size hint should come from and why it might be missing in my windows test. That is indeed strange then.

For me this does work also when decrypting:

btw. this does not work on the decrypting side because kleopatra there apparently does not provide a size hint. So it goes:

Oh my, so I have not really tested this for nearly three months and had my head in the send when reviewing it. I really need to apologize for that. The performance improvement is _not_ what I hoped for if it is even there.

Works good enough for me

Fixed.

secring.gpg is only used by unsupported legacy versions of GnuPG. Since 2.1 it is not anymore used.

So if I have \MyDirectory\pubring.pgp and MyDirectory\secring.pgp files, how do I use the --homedir option to access those?

Should be fixed now; see commit above.

FWIW: WriteFile and write are more different than in using a HANDLE vs. a libc file descriptor. Despite that a HANDLE might be a 64 bit pointer, it is guaranteed that the value fits into a 32 bit variable. But they still index different objects. The return code and error values are also different.

Much simpler: write is only used in the callbacks and over there gpgme_io_writen[n] shall be used anyway.

it's not hard to fix that header to actually provide a sensible write(), avoiding the issue listed on the mailing list, where there was no return to check:

This is not really what the issue here is talking about. This issue was about "merging" multiple keyrings into a single view. If I understand you correctly you want to have matching pubrings and secret key directories for different applications. That is fully covered and what many users do by setting GNUPGHOME through the environment, the --homedir option or the windows registry.

Did anything get implemented to handle this? We have a central network file share where we store our public and secret key rings. We have several different applications that access these key rings. I'm trying to convert one of them from using gpg.exe via the command line with the --keyring and --secret-keyring paramters to using gpgme, but I don't see a way to specify the keyrings. Any help would be appreciated.

works now, Gpg4win-4.1.1-beta295

@ikloecker Thanks for your comment. I put a comment in the commit.

Note that this may not work for Python 2.7, but since those are just examples that doesn't matter that much.

So, here are fixes. I'll apply soonish.

In T6466#169934, @werner wrote:

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

To test this you need to create an OpenPGP key without signing capability.

The actual error is in gpgme. CreateProcess is called with "gpgtar" but "gpgtar.exe" must be used.
This has been fixed with commit rM0c29119e061c. The reason why we didn't noticed the real cause of the problem is that the CreateProcess error shows up in the gpgme-w32spawn helper which has no good way for returning errors.

Fixed in 1.19.0.

Fixed in 1.19.0.

Fixed in 1.19.0.

You could configure gpgme with