Looking at sign_file I can see several places though where it does goto leave before gcry_md_open is called on md. So the fix seems obvious to initalize md to NULL so that the gcry_md_close in the leave part does not work on an uninitialized variable.

gpg (GnuPG) 2.4.4-beta56
libgcrypt 1.11.0
gpg -z0 --yes --batch -esu ldata-test -r ldata-test 10gb-random.dat > 10gb.gp 13,37s user 22,54s system 95% cpu 37,421 total

Please excuse my question but this issue has been WIP for 8 months. I think it was forgotten a bit. Especially since we are not shipping Okular for general signing of PDF documents this issue might help as a stopgap for Smartcards which we do not yet support natively and reduce the pressure a bit to add more PKCS#15 smartcards which can currently be used with Adobe and Mozilla NSS through their proprietary PKCS#11 modules. So I would like to raise the priority for this a bit. But I don't think high is appropriate. That would be for werner to decide.

If you tested it yourself I would say this is enough to move such a task to resolved. If someone else should test it you should remove yourself as the assignee. I will test this by comparing 2.4 performance to master. We need to clean up the WIP tasks in our workboard.

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

In T6775#177408, @werner wrote:

Are you sure this is from a regular Outlook installation and not the common web based outlook? Please enable GpgOL logging and share the log with us. Do not use production keys or messages.

There should not be an exception "Invalid crypto engine" in that call. I expect that gnupg errors out immediately if the parameter with tofu is given while instead it should print a warning and show no information. Or of it errors then Invalid Crypto Engine is definitely the wrong error for that.

I got an idea. Since the gnupg manual is part of that submenu I will include the gnupg manual in Gpg4win. Not sure yet what to do about Linux since we don't have the manual there as PDF. Maybe just an online link to the GnuPG documentation in that case.

Sorry took a while to download all the debug info. Maybe we have different libical versions and this is a libical issue.

I just noticed this because it was accidentally assigned to me and WIP. Since you already mention it in T6325 I would close this as a duplicate of T6325 because at least they can be tested together and testing is the only thing left here that it works with the next 2.2 version.

I have another one, a bit hard to report upstream since it is related to the event and that contains personal information. So I will forward you the event in question privately. It is an ics file attached to a mail, I select "open with Korganizer" and when I hit "merge into existing calendar" it crashes with the debug output:

This works now. Tested both decrypt and encrypt. Sadly just one commit after GPGME 1.23.0 but this was a miscommunication because I was a bit unavailable :( But we can patch this into our installer.

You are right, this is a new feature that could be useful but is now in high demand and not a bug so Wishlist is more appropiate.

IMO for LDAP we should not warn at all. Because there it is possible to remove certificates.

In T6637#176910, @fse wrote:

OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.

I opened T6771 for this because this issue is done.

In T6766#177137, @ikloecker wrote:

I haven't added the possibility to start a group certification directly from the confirmation message.

That output was also misleading,. that was from before I added the ignore-crl-extension in there. I was confused because I still got the error:

So dirmngr already has that option.

I think this was fixed with the fix for https://dev.gnupg.org/T6534

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

Fix was trivial, the classical cancel is not an error problem in the QGpgMEChangeExpiryJob

This has sparked my curiosity.

This happens when cancelling the password entry on normal keys, too. The strange thing is, the changeexpirycommand already checks if "err.isCancelled" and should do nothing in that case.

Tested and there are no available actions. Works.

Ok then we can resolve this. Because I don't want to change the code there too much since it is about a plaintext leak which we cannot reliably reproduce so any change there we cannot really test if it brings up the plaintext leak again. And for users that have problems with the changing of the mail we can point them to the workaround.

Mh, let us concentrate in here on error messages. I was thinking "but what about disable-dirmngr in the settings" then all publish / refresh / receive actions should be disabled or invisible. So that is better something for a different task.

This issue might be a bit to general, some things like avoiding bad error messages are more important then a fully nice solution. A nice solution IMO would make all the "publish on keyserver" actions / checkboxes invisible in that case. If a restart is required when the setting changes that is ok in my book because the way we use "none" is intended that our entry level packages have "none" defined in the global config. Of course if a user then manually enters a value when none is set we would also need to bring up a message box stating that a restart is required for the change to take effect.

I tend to give this high priority since our SecOps state that the creation of non vs-nfd compliant keys is inhibited by our software by default (at least in the UI) I mean no one complained and it is not a regression but this should be fixed soonish. But this does not neccessarily mean before the next release.

Yes, it consists of libkleo DocAction actions which are invisible unless they find the document which they would open. I expect that I can somehow find the menu element and then hide it. But a patch against KXMLGui to hide empty submenus automatically might be a better use of our time. So I put this in the backlog and if someone wants to pick it up in some downtime feel free to fix this :)

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.

Since @ebo did not really know how to test I just checked that it is passed to gpg to resolve this issue.

Ah nevermind missing icons were related because I also removed the highcolor icons for testing.

Mmh, on further checking I notice that some icons are missing though. Need to investigate where they went. I basically just took the inst-breeze.nsi file, and removed all the NSIS things and did a sort -u on it to create the list of icons.

So, I smashed this all together. The icon subset and the cross compile patch, and my time for first startup was 5 seconds then once with procmon enabled 7 seconds and now with a reduced set of icons I am down to Kleopatra to 1.7seconds. The icon subset is just 1.4mb. With all the icons we would have installed for Okular and Kleopatra. I don't have enough time to clean this up today to push it but this looks very good.
Although I am thinking to add a way to kicontheme maybe as a global variable to provide the name for the resource file so that we can properly switch between breeze-dark and breeze.

Ok. Both notepad and file encryption now again produce errors as expected. So the new override would just be a new feature and no longer a regression.

And yes in gpgsm.conf both the extensions are also marked with ignore-cert-extension.

While remembering this I added to our standard.conf (and for testing first to my local conf):

For testing with file encryption and notepad you can use this chain which is valid but does not provide a valid CRL for us

We just realized that similar to what we had in GpgOL ( https://dev.gnupg.org/T6701 ) that AlwaysTrust is used by default. And this will now result in the behavior which I also mentioned in our meeting that without question it encrypts to any S/MIME certificate. Without any warning that it is not VS-NfD compliant to do so.
This must be fixed because otherwise we show an operation as VS-NfD compliant, e.g. to encrypt to a certificate with a broken CRL. Which is not VS-NfD compliant because the CRL check was not done.

Since I tested this both with valid and invalid filenames on linux and on windows I set this to resolved.

The URL was just wrong for Windows. I added debug output and the results are different:

Yes and I get the same result with PNG files. But calling shell execute with such an url looks strange to me, I will try QUrl::fromLocalFile as we use in Kleopatra.

Moving the definition and changing it to the name of the po file worked.

Pretty sure its the translation domain. Thanks! Will try to fix that tomorrow

According to werner the gnupg tools use GetCommandLineW even when they are not build with -municode.
So a solution could be to build gpgme-w32-spawn with -municode and start the child process with CreateProcessW, this would also solve the problem that GnuPG could itself be installed into Paths which are not representable in the local 8 bit encoding.

I think that if we know that GnuPG is not encrypting to expired keys we need to use the X icon for that key and disable the sign/encrypt button until this key is removed.